[cairo] Static caches and thread-safety

[Owen Taylor]

On Fri, 2004-11-12 at 10:49 -0500, Carl Worth wrote:
> On Fri, 12 Nov 2004 10:34:13 -0500, Keith Packard wrote:
> > I think we can manage to figure out enough locking stuff to let these 
> > caches be shared.
> 
> There's non-zero maintenance cost of adding locking to cairo. I don't
> know what the cost of not automatically sharing caches between threads
> would be. (And the clone approach would still let applications get the
> sharing). I think we may just have some premature optimization here.

It's not "sharing between threads", right? As I understand it, it's 
mostly automatically sharing between cairo_t. Having to have a global
Cairo object for the library (like FT_Library) strikes me as
inconvenient, especially if you had to add a manual locking layer
around it.

Various possible concerns about actually locking in Cairo:

 - Are there systems people want to use Cairo on without basic
   non-recursive mutexes/locks? Maybe? Are there systems that 
   support threads without such basic locks? I very much doubt
   it, so we can stop worrying about that.

 - Are there cases where people want to use different threading
   systems then the system default threading?
   
   This was a big concern when we first added threading to GLib,
   so when you initialize GLib, you provide a VTable of thread
   primitives (mutexes, condition variables, etc.) However, it
   turned out the usage of non-system thread libraries was basically
   a dying remnant, and in that light using the vtable was a bit
   of a mistake, it prevents us from using all the capabilities
   of more capable threading systems.

 - Does using thread locking require linking to another library,
   and if so, is there a performance penalty for that?

   Traditionally on Linux, using threads required linking to
   -lpthread, and linking to -lpthread can slow apps down
   5-10%. (More if you use getc() a lot.)

   However, as Keith points out, on GNU libc pthread functions are
   now stubbed with weak aliases in libc, so you can just use 
   them, and if the app doesn't link with -lpthread, they do 
   nothing.

   So, no problem on Linux. Elsewhere? I don't know.

 - Is figuring out the right compilation flags for threading across
   systems hard?

   Unfortunately, yes. The threading part of GLib's configure.in
   is a couple of hundred lines. But a lot of that may be
   overcomplicated for what we need here. A good starting point
   might be to just AC_CHECK_HEADERS([pthread.h]) and if 
   pthread.h is fine, try to use it. It will break on one system
   or another, but the people who find breakages can suggest
   fixes.

> If we could restrict the locking to the X-specific backend then yes, I
> would feel much more comfortable.

I don't think this is going to help you at all. Basically, the
non-pthread systems (like Windows) tend to be very well defined about
how you use threading. The problems you are going to hit, if any,
are *BSD (-lc_r? maybe on Tuesdays), AIX, and to the extent one
cares, all the old unices.

Regards,
							Owen

-------------- 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/20041112/3dab4f54/attachment.pgp