Re: bugs regarding late g_thread_init() calls

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Qua, 2007-01-03 at 11:39 +0100, Tim Janik wrote:
> On Wed, 3 Jan 2007, Gustavo J. A. M. Carneiro wrote:
> 
> > On Qua, 2007-01-03 at 00:57 +0100, Tim Janik wrote:
> >> On Tue, 2 Jan 2007, Gustavo J. A. M. Carneiro wrote:
> >>
> >>> On Ter, 2007-01-02 at 14:34 +0100, Tim Janik wrote:
> >>>> 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.
> >>>
> >>>  In PyGObject it is virtually impossible to guarantee that
> >>> g_thread_init() gets called before using some other GLib APIs.  At least
> >>> not without changing the API.  That's because g_thread_init() is called
> >>> by the python function gobject.threads_init(), but you obviously can't
> >>> call gobject.threads_init() without importing gobject first, and of
> >>> course "import gobject" already calls some GLib APIs...  This is a very
> >>> tricky problem :|
> >>
> >> what glib APIs are you calling there and why couldn't g_thread_init() be the
> >> first glib function to call there?
> >
> >  For instance, g_boxed_type_register_static and
> > g_quark_from_static_string, probably others.  We need to call these on
> > python module initialization.
> >
> >  We don't want to call g_thread_init() unless the programmer requests
> > to, in order to not suffer threading support performance penalty, of
> > course..
> 
> in the single threaded case, the overhead is negligible

  Well, maybe that's true for Linux systems with NPTL, but I have some
doubts you could generalize this statement to all platforms.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.