This was previously discussed here, but was sort of hidden in a technical discussion so it got no replies. I'm starting over in order to reach a wider target for the discussion.
I'll start with the proposal and then explain the reasons for it: Starting with next glib release: * libgobject links to libgthread * g_type_init() starts with: #ifdef G_THREADS_ENABLED if (g_thread_supported()) g_thread_init (NULL); #endif This means that everything above gobject can rely on thread primitives being availible, and that global stuff in glib (mainloop, gslice, globals, etc) are threadsafe. It also means that simple apps that just use the datatypes and utilities in glib (and don't use gobject) won't require threads. Note however, that this doesn't mean that GDK/GTK are threadsafe by default. That is an additional thing, and it can't even be enabled by default because it requires changes in non-threadsafe applications. So, apps still need to call gdk_threads_init(). It also allows applications to call g_thread_init() before g_type_init() in order to specify custom threading primitives. So, what is the reason for this? The current system (apps have to call g_threads_init() before any other glib functions) works for applications that need to use threads. However, it breaks down when libraries or plugins need to use threads. Since its not allowed to call g_thread_init() late these libraries can't use threads at all unless the application initialized them, which many don't. Additionally, and part of the problem, is that current glib allows late initialization, or at least it doesn't crash in flames if you do so. However, there is no guarantee that this doesn't break in weird ways as a lot of threadsafe code doesn't correctly handle late thread initialization (including libgio, see bug 595757). In fact, outside of libglib its not really possible to sanely handle it. ORBit2 (and thus gconf which uses it) initializes threads late, so in practice most applications actually initialize threads, but in a broken and risky way. Historically we've avoided threads a lot because the cost of just having basic thread-safety was to high. But, with the current situation (futexes/NPTL/g_slice) things have improved a lot on the software side, so the costs are not as bad anymore. And threads are starting to become more important these days too, with multi-core processors and gio using threads for async local i/o. So, while I personally still recommend people to not use threads unless they have a very good reason, I think that we are now at a place where its used widely enough and is important enough that we need to be able to rely on the basic threading primitives in our libraries and plugins by default. It would be nice to be able to drop the whole thread initialization issue for Gnome 3.0. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
