Re: bugs regarding late g_thread_init() calls

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 ( ):
 	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. ), 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
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. # (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)
-  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) ;-)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]