Re: bugs regarding late g_thread_init() calls

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

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



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