"thread vtables" (Was: Re: [cairo] Static caches and thread-safety)

[Owen Taylor]

On Sat, 2004-11-13 at 15:01 -0500, MenTaLguY wrote:
> On Fri, 2004-11-12 at 11:20, Owen Taylor wrote:
> >  - 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.
> 
> One other situation in which it's valuable is when an application uses a
> "magic" library that wants to hook the platform's thread primitives to
> work properly with multithreading.
> 
> The boehm collector, which Inkscape uses, is one such library.  At
> present we're not using threads (so far it's not been worth the
> trouble), but we may want to do so eventually in a limited fashion.
> 
> Glib (because of the vtable) shouldn't be a problem, but we'd also like
> to use cairo eventually.  It'd be really awkward to have to choose
> between cairo, libgc, and threading (well, pick two).

Looking at gc_pthread_redirects.h, it doesn't seem to redirect 
mutex_lock/unlock at all, just create/join/detach/sigmask and similar.

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/20041113/0d3d4098/attachment.pgp