[cairo] Re: Thread-specific linked-list for locked FT_Face objects

[Keith Packard]

On Tue, 2007-02-13 at 12:22 -0500, Owen Taylor wrote:

>  A) You could try to wrap all relevant bits FreeType, so that you could
>     have a  big global lock around FreeType inside of cairo.

FreeType has pushed the entire locking problem back to us. I suggest
that we start by circumscribing usage of FreeType and discovering which
sequences must be atomic within cairo. Atomic sequences would then be
protected by a per-FTLibrary mutex (as cairo should use a single
FTLibrary, this can be a global mutex).

>  B) You could expose a big global lock around all FreeType operations
>     to the application. Could be very prone to deadlock creation.

I'd suggest we will have to expose the lock that cairo uses to pango so
that it can correctly interoperate with cairo's use of the same
FTLibrary structure.

An alternative would be to wrap more of the FreeType API in cairo
cloathing and perform the necessary locking within the cairo library;
this doesn't seem commensurate with the current pango implementation
though, which shares FreeType usage across several output modules.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070213/4e6b2f39/attachment.pgp