Re: bugs regarding late g_thread_init() calls

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

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

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