[cairo] Locking policy

[Keith Packard]

I added pthread mutexes to lock the various caches in cairo and (not
unexpectedly) this uncovered some 'issues' related to the locking code
that is in place.

First off, we need to list all of the mutexes and either assert that
there are no simultaneous locks or define a locking order when there
are.

Second, we need to mark areas of code which must be protected by each
lock, and track down the call graph to the bottom ensuring that both the
above ordering rules are followed as well as avoiding any recursive
locks.  We could use recursive mutexes, but those are less well
supported, and, in particular, there is no standard initializer for
them.  Glibc provides a initializer, but only as a GNU extension.

For now, I'm using recursive mutexes and 'roadster' appears to work
again, but I'm not willing to live with that; we're essentially
executing some code under a lock in some cases which is executed
unlocked in other cases.

The case that I found this evening was in the unscaled font cache;
ejecting an entry from that cache is done (oddly enough) with the cache
lock held, but the act of removing an entry from the cache attempts to
re-acquire the lock.  Oops.

I'm afraid most of this process is just tedious review work, not
exciting new development, but ensuring that cairo is deadlock-free is
rather important.

-keith

-------------- 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/20050626/25255a2d/attachment.pgp