Re: bugs regarding late g_thread_init() calls

[Martyn Russell <martyn imendio com>]

Tim Janik wrote:
> hey all.

Hi,

> since the very early inception of the glib threading system, the docs
> say ( http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html ):
>  	You must call g_thread_init() before executing any other GLib
>  	functions in a threaded GLib program.
> 
> multiple code portions rely on that, one such example is the GSlice code.
> i've thusly added a warning to GSlice code to catch cases where applications
> are calling g_thread_init() wrongly and as a consequence mess up GSlice state.
> 
> this tunred out to actually be relevant in a significant number of apps,
> related bug reportss are:
>    http://bugzilla.gnome.org/show_bug.cgi?id=331853 # (WONTFIX) Handle using gslice before g_thread_init() better
>    http://bugzilla.gnome.org/show_bug.cgi?id=343490 # (FIXED) gnome_program_init() causes g_thread_init() to be called too late
>    http://bugzilla.gnome.org/show_bug.cgi?id=391278 # (OPEN) gst programmes don't call g_thread_init early enough
> 
> it has been claimed in a number of places that adding the above warning
> is breaking glib ABI. this is not the case, because the requirement has
> always been there, it just wasn't as strictly enforced.
> possible alternatives also have been suggested and i'll briefly sum them up:
> 
> 1) GLib should auto-initialize the threading layer by calling
>     g_thread_init (NULL) internally on demand.
>     - this breaks the existing API where a custom threading function vtable
>       can be specified as argument to g_thread_init(). allthough in practice,
>       most programs will only want g_thread_init (NULL) initialization these
>       days (the need for plugging a threading vtable was much higher in the
>       late nineties when most systems didn't provide the same POSIX thread
>       API).

I think if you are going to use your own threading implementation, it
should be something that you initialise the library with, if not, glib
should fall back to the defaults.

>     - there is no single glib internal entry point which could perform
>       automated thread system initialization. and adding such initialisation
>       code to 1000+ exported glib symbols would be grossly excessive.

Yes, quite problematic but I think of those 1000+ exported symbols I
wonder how many really need threading initialised before being used.

> 2) Auto-initialize via g_thread_init (NULL) in gnome_init().
>     + this has already been done for newer GNOME libs, see:
>         http://bugzilla.gnome.org/show_bug.cgi?id=343490 

This is my idea of a temporary solution. It doesn't really address the
issue properly.

> 3) Auto-initialize with g_thread_init upon gtk_init
>     + similar to gnome_init, gtk_init() could call:
>         if (!g_threads_got_initialized)
>           g_thread_init (NULL);
>       this is not expected to be a problem for Gtk+ applications these days,
>       and will fix too-late threading system initialization which is currently
>       performed by file system backends of the new Gtk+ file selector.

Again, this feels more like an after thought and not really the ideal
solution here.

> 4) Patch up GSlice and other code to cope with late g_thread_init() calls
>     + bug #331853 investigates this to some extend for GSlice, and it's
>       probably possible, but requires significant implementation work.
>     - however, other glib threading initialization portions still need to be
>       evaluated wrg to supporting late g_thread_init() and may require more
>       work.
>     - even if it could be wokred out for all of the current glib systems,
>       we can't be sure to be able to support arbitrarily late g_thread_init()
>       calls in the future.
> 
> at this point, i don't think (4) really has to be investigated/implemented,
> and i don't see spare resources for it anyway.
> however i'd like to propose the implementation of (3) to ease fixing of most
> non-gnome gtk applications.

I think the question that needs answering first is:

  What in glib requires g_thread_init() to be called first?

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

I would probably vote for initialising on demand.

-- 
Regards,
Martyn