Re: bugs regarding late g_thread_init() calls

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 ( ):
 	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

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.


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