Re: When to call g_thread_init(), again...



On Fri, 15 Aug 2008 10:58:59 +0300 Tor Lillqvist wrote:

> The documentation for g_thread_init() says (in the stable branch):
> 
>   "You must call g_thread_init() before executing any other GLib
>    functions in a threaded GLib program."
[..]
> The real use case reported on gtk-list looked much more innocent,
> though. Its main() started with:
> 
>   gtk_init (&argc, &args);
> 
>   html = gtk_html_new_from_string (html_source, -1);
> 
> How can the poor application programmer know that
> gtk_html_new_from_string() will cause g_thread_init() to be called
> deep in the bowels of libORBit2? What should be fixed? Should gtkhtml
> be fixed to call g_thread_init() itself, from functions that might
> conceivably be the first ones that user code calls? But still that
> wouldn't help strictly speaking, as gtk_init() of course also calls
> lots of GLib functions, so it is too late to call g_thread_init()
> somewhere in libgtkhtml in this case. Should ORBit2 g_error() out if
> it notices that it wants to use threads but g_thread_init() has not
> been called, instead of calling it itself?

Yes to that last bit.  If it really truly does matter that
g_thread_init() be called before other glib functions, then no *library*
should *ever* call g_thread_init().  If a library needs it, it should
check g_thread_supported(), and g_error() with a useful error message
if it fails.

That way, the programmer of the app knows the first time they test-run
their app that they've done it wrong.

> So, should the requirement for g_thread_init() being called before any
> other GLib API, if it is called at all, be removed? (After all,
> failing it apparently is harmless anyway, on Linux.

I don't remember the specifics (or even the generalities), but a few
years ago I ran into a situation with a *very* hard-to-track memory
corruption bug on Linux... the solution was of course to call
g_thread_init() before anything else.  I don't know if the situation
has improved since then, but it seems safer just to err on the side of
bailing out rather than hoping things will be ok.

	-brian


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