After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 343490 - gnome_program_init() causes g_thread_init() to be called too late
gnome_program_init() causes g_thread_init() to be called too late
Status: RESOLVED FIXED
Product: libgnome
Classification: Deprecated
Component: general
2.14.x
Other All
: Normal normal
: ---
Assigned To: libgnome maintainer
libgnome maintainer
Depends on:
Blocks:
 
 
Reported: 2006-05-31 09:50 UTC by Tor Lillqvist
Modified: 2006-10-23 13:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tor Lillqvist 2006-05-31 09:50:36 UTC
The docs for g_thread_init() say that it should be the first GLib function called in a threaded program. It's unclear whether "threaded program" there means a program that actually creates threads (using the GThread API), or a program that calls g_thread_init(). Anyway, it doesn't matter for this discussion.

gnome_program_init() causes g_thread_init() to be called (unless it has already been called). The problem is that by the time libgnome gets around to calling g_thread_init(), many other GLib functions have already been called, for instance g_malloc(). libgnome can't know whether the program will create GThreads or not. If the program will create GThreads, the call to g_thread_init() in libgnome definitely happens too late. (And if the program won't create GThreads, why then call g_thread_init() at all...?)

So, I am not really sure what is the correct thing to do? Remove the call to g_thread_init() from libgnome and tell app maintainers to add it to the immediate start of main() in all threaded GNOME apps, where it should be, according to GLib docs? Scary. Or relax that requirement in glib? (See also bug #331853) That seems to be the de facto situation anyway, at least on Linux, and on Win32 after fixing bug #331367, it doesn't in fact hurt to call various GLib function before g_thread_init() even in a threaded program.
Comment 1 Tor Lillqvist 2006-05-31 09:53:40 UTC
Or should the call to g_thread_init() simply be moved away from bonobo_activation_pre_args_parse() to the start of gnome_program_init()?
Comment 2 Tim Janik 2006-05-31 10:23:49 UTC
i think the correct thing to do here is what you outlined in comment #1.
at the start of gnome_program_init(), it shoudl do:
  if (!g_threads_got_initialized)
    g_thread_init (NULL);
that'll allow programs which have to call glib functions before gnome_program_init() to do:

main() {
  g_thread_init (NULL);
  /* use glib here */
  gnome_program_init();
}
Comment 3 Kjartan Maraas 2006-10-23 12:56:15 UTC
Like this?

diff -u -p -r1.91 gnome-program.c
--- libgnome/gnome-program.c    10 Jul 2006 13:32:19 -0000      1.91
+++ libgnome/gnome-program.c    23 Oct 2006 12:55:53 -0000
@@ -1739,6 +1739,9 @@ gnome_program_init (const char *app_id, 
     GnomeProgram *program;
     va_list args;
 
+    if (!g_threads_got_initialized)
+        g_thread_init (NULL);
+
     g_type_init ();
 
     va_start(args, first_property_name);
Comment 4 Tim Janik 2006-10-23 13:00:53 UTC
yes, maybe even accompanied by a comment:
  /* g_thread_init() has to be the first GLib function called ever */
so people don't try to add g_print() or g_option* or whatever else function calls before that.
this does require some testing of course, but should mostly be ok except for programs that are broken anway (and e.g. call g_thread_init() on their own *after* gnome_program_init()).
Comment 5 Kjartan Maraas 2006-10-23 13:11:31 UTC
I added the comment too.