Re: bugs regarding late g_thread_init() calls

[Behdad Esfahbod <behdad behdad org>]

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.

-- 
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