Re: bugs regarding late g_thread_init() calls

[Behdad Esfahbod <behdad behdad org>]

On Wed, 2007-01-03 at 00:59 +0100, Tim Janik wrote:
> 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 ;)

No.  The point I was trying to make was that "on-demand" calling of
g_thread_init doesn't work.  Because one thread may call a function that
triggers calling g_thread_init() and another thread may be inside a
G_LOCK/G_UNLOCK pair, with the G_LOCK having been ignored because of no
threads, and the G_UNLOCK call will be doomed.

As for calling g_thread_init() in gtk_init(), this means gtk+ has to
link to gthread, which it's not currently.  Not that it's a problem.


> > behdad
> > http://behdad.org/
> 
> ---
> ciaoTJ
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759