Re: bugs regarding late g_thread_init() calls

[Michael Meeks <michael ximian com>]

Hi there,

On Tue, 2007-01-02 at 14:34 +0100, Tim Janik wrote:
> 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.

	This doesn't appear in the gtk+-2.6 docs (cf.
http://www.gtk.org/api/2.6/glib/glib-Threads.html ), indeed it arrived
quite 'recently' [ in sluggish-ISV-months ]

revision 1.50
date: 2005/05/20 17:15:37;  author: matthiasc;  state: Exp;  lines: +8 -0
2005-05-20  Matthias Clasen  <mclasen redhat com>

        * glib/tmpl/threads.sgml: Add a paragraph about thread
        safety of GLib data structures.

	Which (I imagine) first shipped in glib-2.8.0 - August 2005; < 18
months ago.

	Of course, the argument "it was always like that" is perhaps better,
though Owen suggests it wasn't always :-)

>    http://bugzilla.gnome.org/show_bug.cgi?id=331853 # (WONTFIX) Handle
> using gslice before g_thread_init() better

	Reading Tor's patch it appears (to uneducated me), to fix this for
GSlice - and thus avoid rather a disruptive change.

	Having said that, I think Tor's patch could prolly be made somewhat
simpler; by abandoning the main_thread_self variable, and just doing the
g_private_set inside the _gslice_thread_init_nomessage call - indeed, if
we were suitably 31337 we could transfer the old private value to the
new threaded version; is this a complete 'fix' ? (and/or would it / does
it work ? [ uncompiled, etc. ;-] ;-)

--- glib/gslice.c       (revision 5207)
+++ glib/gslice.c       (working copy)
@@ -386,7 +386,11 @@
     }
   if (!sys_page_size)
     g_slice_init_nomessage();
-  private_thread_memory = g_private_new (private_thread_memory_cleanup);
+  {
+    GPrivate *tmem = g_private_new (private_thread_memory_cleanup);
+    g_private_set (tmem, private_thread_memory);
+    private_thread_memory = tmem;
+  }
   allocator->magazine_mutex = g_mutex_new();
   allocator->slab_mutex = g_mutex_new();
   if (allocator->config.debug_blocks)

	Of course, an early init for all gtk+ apps is a good solution that
should catch most cases; but take pity on ORBit2 that can be used in a
non-threaded scenario; and (AFAIR) likes to use glib routined to parse
it's options at init time, one of which is "turn-on-threading" (or
similar) ;-)

	HTH,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot