Re: When to call g_thread_init(), again...
- From: "Brian J. Tarricone" <bjt23 cornell edu>
- To: gtk-devel-list gnome org
- Subject: Re: When to call g_thread_init(), again...
- Date: Fri, 15 Aug 2008 01:51:46 -0700
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]