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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list