hey all. since the very early inception of the glib threading system, the docs say ( http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html ): You must call g_thread_init() before executing any other GLib functions in a threaded GLib program.
multiple code portions rely on that, one such example is the GSlice code. i've thusly added a warning to GSlice code to catch cases where applications are calling g_thread_init() wrongly and as a consequence mess up GSlice state. this tunred out to actually be relevant in a significant number of apps, related bug reportss are: http://bugzilla.gnome.org/show_bug.cgi?id=331853 # (WONTFIX) Handle using gslice before g_thread_init() better http://bugzilla.gnome.org/show_bug.cgi?id=343490 # (FIXED) gnome_program_init() causes g_thread_init() to be called too late http://bugzilla.gnome.org/show_bug.cgi?id=391278 # (OPEN) gst programmes don't call g_thread_init early enough it has been claimed in a number of places that adding the above warning is breaking glib ABI. this is not the case, because the requirement has always been there, it just wasn't as strictly enforced. possible alternatives also have been suggested and i'll briefly sum them up: 1) GLib should auto-initialize the threading layer by calling g_thread_init (NULL) internally on demand. - this breaks the existing API where a custom threading function vtable can be specified as argument to g_thread_init(). allthough in practice, most programs will only want g_thread_init (NULL) initialization these days (the need for plugging a threading vtable was much higher in the late nineties when most systems didn't provide the same POSIX thread API). - there is no single glib internal entry point which could perform automated thread system initialization. and adding such initialisation code to 1000+ exported glib symbols would be grossly excessive. 2) Auto-initialize via g_thread_init (NULL) in gnome_init(). + this has already been done for newer GNOME libs, see: http://bugzilla.gnome.org/show_bug.cgi?id=343490 3) Auto-initialize with g_thread_init upon gtk_init + similar to gnome_init, gtk_init() could call: if (!g_threads_got_initialized) g_thread_init (NULL); this is not expected to be a problem for Gtk+ applications these days, and will fix too-late threading system initialization which is currently performed by file system backends of the new Gtk+ file selector. 4) Patch up GSlice and other code to cope with late g_thread_init() calls + bug #331853 investigates this to some extend for GSlice, and it's probably possible, but requires significant implementation work. - however, other glib threading initialization portions still need to be evaluated wrg to supporting late g_thread_init() and may require more work. - even if it could be wokred out for all of the current glib systems, we can't be sure to be able to support arbitrarily late g_thread_init() calls in the future. at this point, i don't think (4) really has to be investigated/implemented, and i don't see spare resources for it anyway. however i'd like to propose the implementation of (3) to ease fixing of most non-gnome gtk applications. --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
