Proposal: Enable threads by default
- From: Alexander Larsson <alexl redhat com>
- To: "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Proposal: Enable threads by default
- Date: Thu, 26 Nov 2009 14:35:36 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]