Re: bugs regarding late g_thread_init() calls

[Tim Janik <timj imendio com>]

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 and in the 
multithreaded case you need g_thread_init() anyway.
so you're best off with calling g_thread_init() right before g_type_init().

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

---
ciaoTJ