Re: bugs regarding late g_thread_init() calls

[Tim Janik <timj imendio com>]

On Tue, 2 Jan 2007, Behdad Esfahbod wrote:

> On Tue, 2007-01-02 at 09:55 -0500, Martyn Russell wrote:
> > With my relatively limited experience of glib, all I can think of is:
> >
> >   - gasyncqueue
> >   - gmain
> >   - gthread
> >   - gthreadpool
> >   - gslice
> >   - gtimer
> >
> > If it is a small portion of the code (i.e. just the few modules listed
> > (above) then perhaps it should be initialised on demand. However, if
> > it
> > is needed in a lot of places and/or the impact of calling
> > g_thread_init() is relatively minor anyway, then perhaps a g_init()
> > function is needed which we expect users to call first (like
> > gtk_init())
>
> On-demand initialization cannot be done without a performance penalty.
> It's not just about what glib does internally.  App code depends on the
> fact that g_thread_init() is called before all other glib functions (and
> glib-using functions).  For example, I use G_TRYLOCK() in Pango.  That
> macro does nothing if threads are not initialized.  Now if
> g_thread_init() is called after that G_TRYLOCK() and before the
> respective G_UNLOCK(), disaster happens.  So, the only way to make it
> happen is to make G_TRYLOCK() initialize threads instead of doing
> nothing.  That means, one would always pay the threads overhead AND that
> will not work, since gthreads is not linked necessarily.

is that a general comment, or are you trying to argue against
adding g_thread_init() to the start of gtk_init() (which is highly unlikely 
to be called between a trylock/unlock pair of pango ;)

> behdad
> http://behdad.org/

---
ciaoTJ