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

[Owen Taylor]

On Tue, 2007-02-13 at 10:36 -0800, Keith Packard wrote:
> 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.

My worry about this approach is deadlocks:

 cairo_scaled_font_create()

for example, does:

 _cairo_scaled_font_map_lock();
 [... call into backend ]
 _cairo_scaled_font_map_unlock();

With an exposed cairo_ft_lock(), this would create a potential deadlock
if anybody called cairo_scaled_font_create() after locking the FT lock,
since you then have both lock orders:

 - Lock the font map; Lock the FT lock
 - Lock the FT lock; lock the font map

A complicated set of rules about what functions you could call with 
FT locked would be a invitation to all sorts of subtle hard-to-reproduce
problems.

> 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.

I'm not sure what you mean by this. Right now, Pango exposes the ability
to get a FT_Face in the public API. (Actually, not fully public API, but
rather reduced-stability engine-and-backend API.) No matter what
approach we take, that can't be made thread-safe as long as FreeType
is not thread-safe.

But almost anything that Pango does with FreeType can (theoretically) be
reduced to atomic operations that could be individually wrapped by
cairo.

The most problematical part might be harfbuzz, which needs access to
entire raw tables from the FreeType font. There's no problem with doing
that with an API that simply copies the data out of the font into a
malloc'ed segment, but if you wanted to try and share the mmap's that
FreeType creates, then things get trickier.


					- Owen