On Sat, 2009-12-05 at 19:45 -0500, Adam Goode wrote:
> > I'll start with the proposal and then explain the reasons for it:
> >
> > Starting with next glib release:
> > * libgobject links to libgthread
> > * g_type_init() starts with:
> >
> > #ifdef G_THREADS_ENABLED
> > if (g_thread_supported())
> > g_thread_init (NULL);
> > #endif
> >
> > This means that everything above gobject can rely on thread
> primitives
> > being availible, and that global stuff in glib (mainloop, gslice,
> > globals, etc) are threadsafe.
>
> Will this enable my library that uses only GSlice to be used from
> non-GLib-aware applications that use different threads?
>
> Specifically, I have a library that internally uses GSlice and
> GHashTable, but I don't expose any GLib details. I link my library
> with
> Java and other applications that use pthreads. Will this make GSlice
> work OK? How can I avoid calling g_thread_init() from within my
> library?
This change only affects the case where the appliation uses gobject (and
thus initializes it early). If g_type_init is not called then there is
no difference wrt the current behaviour.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alexander larsson gmail com
He's a lonely hunchbacked card sharp She's a plucky hip-hop college professor
who dreams of becoming Elvis. They fight crime!
Attachment:
signature.asc
Description: This is a digitally signed message part