Re: bugs regarding late g_thread_init() calls

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]