Re: Gnome/Gtk and thread safety

[otaylor redhat com]

Andy Tai <atai atai org> writes:

> Hi, gtk+ and Gnome libraries are generally not thread safe.  Support for
> multithreaded programs (GUI calls can be in different threads) is almost
> an absolute requirement for a modern software framework.  While GNOME's
> main competitor, KDE/Qt, is not thread safe either, other GUI sytem
> calls in OSes like BeOS and 32-bit Microsoft Windows are thread-safe.
> Maybe the GNOME Project should require that newer GNOME software
> foundation blocks like Bonobo and Orbit should be written with thread
> safety in mind, and old stuff like gtk+ and gnome-libs should be
> gradually made thread safe?

Well, I think before you start throwing around "thread safety", you
need to define what you mean by that. There are a lot of different
levels, from:

 - Correct functionality with a manual global lock (GTK+ currently)
 - Automatic acquisition of a global lock (Motif, Xt)
 - Internal data is locked, but data structures still have to
   be locked by user. (GLib, Java actually, etc.) 
 - Automatic acquisition of fine-grained locks (???)

After all, while BeOS tries to go for very fine grained threading,
that's not the norm; as I understand it for MS Windows, you can
work with two different toplevels in two different threads, but
if you want to work with one toplevel in two threads, you have
to introduce your own locking.

As for current work in GNOME and GTK+:

 - All GLib functionality, including the new GObject is supposed
   to correctly lock internal data. You probably won't be able
   to emit signals on one objects from two threads, but you should
   be able to emit signals on two objects each in its own thread.

 - Thread safety is one of the design goals for ORBit2 

 - There is some use of threads in gnome-vfs for fetching data
   in the background. Uses like this will most likely increase
   when we have a thread-safer GObject in GLib-2.0

Making GTK+ thread-safe in the sense of Motif wouldn't be conceptually
hard, just a lot of work, and I'm not really sure that the goal of an
automatically acquired global lock is a good one. Trying to put in
finer grained locking is Hard, and integrating that with GTK+'s signal
system probably falls into the category of "research problem".

We definitely shouldn't lose sight of the fact that threading is a
(sometimes necessary) evil. Full threading is just too hard for normal
programmers to get right. Microsoft seems to have recognized it with
their apartment model with limited sharing, etc.

So, we need to look more at ways of letting programmers take advantage
of threading without having to understand everything that you need to
know to prevent your threaded program from being an unstable, locking
up, quivering mess of locks.

Regards,
                                        Owen