Re: bugs regarding late g_thread_init() calls

[Owen Taylor <otaylor redhat com>]

Some comments about this discussion, in more or less random order.

 * In the past, we've spent quite a bit of time making things work with
   "late" calls to g_thread_init() - allowing this usage has the big
   advantage that an application can use a library that uses threads
   internally without having to know about is.

   And that's really where threads are most useful in many cases: as
   internal implementation details of a library.

   But the way we've done it is never equivalent to a lazy call to
   g_thread_init() - that would require linking all apps to gthread
   and -lpthread, plus adding locking overhead internal to GLib.

   (I actually hadn't realized that late initialization worked, and
   was surprised  a couple of years ago when Matthias pointed it out
   to me in the context of a patch to fix up a place which didn't
   work. I checked through the code and couldn't find any places
   that weren't OK, though I may have missed a few or we may
   have regressed. But if GSlice can be fixed, I think we could
   easily allow late initialization.)

 * Behdad's worry about another thread calling g_thread_init() while
   Pango is in the middle of an operation isn't an issue, because 
   everybody (I think) agrees that g_thread_init() has to be called
   from the *main* thread, before you start threaded operation.
    
 * It does appear that we are pulling in pthread in any case for 
   a standard GTK+ application these days, so perhaps it would
   be worth at least considering whether we wanted to make that
   a hard dependency; considerations:

   - What simplifications could we achieve with such a hard dependency?
   - The only use for libgthread is to avoid a hard pthread dependency;
     if we added such a dependency, would it make sense to make
     libgthread an empty dummy library? (it can't be quite empty
     on windows, since g_thread_init() has to stay in the same DLL)
   - Could g_thread_init() be removed entirely, by making the different
     subsystems lazily initialize themselves? What's the performance
     impact of the necessary GOnce usage for this?
   - What is the performance degradation when you link to -pthread?
     When you initialize GLib threading?

   But going in those directions is a fairly major project.

 * I really wouldn't worry about calls to g_thread_init() with
   anything other than the NULL as the parameter. Though we never
   formally deprecated the usage, there is a fairly warning
   about it in the docs:

   "You should only call g_thread_init() with a non-%NULL parameter 
    if you really know what you are doing."

   If we need to remove the functionality of that parameter, we 
   can always claim that the callers didn't know what they were
   doing. :-)

				- Owen