Re: bugs regarding late g_thread_init() calls

[Tim Janik <timj imendio com>]

On Thu, 4 Jan 2007, Michael Meeks wrote:

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

it has always been like that.
it's also been documented for much longer than 2005 in email threads, irc
discussions, and iirc tutorial docs/threading examples.

> though Owen suggests it wasn't always :-)

he suggests late initialization was made to work at some point, but also
grants that we'd need some new auditing to be sure (besides changing
GSlice).
which is exactly the problem. *if* we support it, we need to *fully* do
that, i.e. keep supporting it. also all docs need to be fixed to not
contradict the support, so no future threading changes are made that
break late initialization.

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

please use diff -up for posting patches.

>     }
>   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;
> +  }

unless you meant to call thread_memory_from_self() here, to initialize
the main thread allocator eagerly, this change doesn't make too much sense.
i.e., did you want to write this?
  private_thread_memory = g_private_new (private_thread_memory_cleanup);
  ThreadMemory *tmem = thread_memory_from_self();
  g_private_set (private_thread_memory, tmem);

>   allocator->magazine_mutex = g_mutex_new();
>   allocator->slab_mutex = g_mutex_new();
>   if (allocator->config.debug_blocks)

i'm not sure we have to do the manual shuffling from Tor's patch at all
though, i'd rather try to fix the g_private usage so it always does the
right thing regardless of whether threading is initialized.

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

huh? does ORBit2 call gtk_init()?

in any case, this thread has seen some good arguments for *not* calling
g_thread_init from gtk_init, in particular the need to link against
libgthread and libpthread.

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

---
ciaoTJ