bugs regarding late g_thread_init() calls

[Tim Janik <timj imendio com>]

hey all.

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

---
ciaoTJ