Re: threads

[Chris Vine <chris cvine freeserve co uk>]

On Sunday 31 October 2004 16:31, Ole Laursen wrote:
> Ian Strascina <istrasci cs nmsu edu> writes:
> > 1 - use GDK threads (as per
> > http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html)
> >
> > 2 - using c++ classes, e.g. those within the Glib namespace --
> > Glib::{Thread,Mutex,...}  (as per
> > http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/group__Threads.h
> >tml)
> >
> >
> > Is either of these methods better than the other, or are they similar
> > (perhaps even display a "wrapper-wrappee" relationship)...???
>
> Well, I've never used the threading stuff, but some of it appears to
> be in glib as you can see here
>
>   http://developer.gnome.org/doc/API/2.0/glib/index.html
>
> and some of it in GDK. So I'd say that the Glib:: stuff is just
> wrappers.

They are different things.  The Glib threading library provides a platform 
independent API for such things as starting threads and creating threadpools, 
and it provides platform independent locking mechanisms such as mutexes.  In 
Unix systems, the Glib threading library is normally just a wrapper for 
pthreads.  Glib, including the main loop, is thread safe (except the Glib 
containers), as it locks all its own static data.

GDK provides an interface to the windowing system (in most Unix systems, X).  
It uses Glib, and GTK+ uses both Glib and GDK.  Unlike Glib, GDK/GTK+ are not 
of themselves thread safe (nor is X), nor do they provide a separate 
threading API (they assume you are using the Glib threading library).  All 
they provide is a global lock (used amongst other things to protect the GDK 
data structures) via the functions gdk_threads_enter() and 
gdk_threads_leave(), so as to allow more than one thread to write to the 
windowing system.

Using the GDK global thread lock is error prone and not a good idea in a 
program of any size.  A well designed program would generally have one 
thread, and only one thread, responsible for the GUI, with which other 
threads communicate via asynchronous to synchronous converters such as pipes, 
or, in the case of glibmm, Glib::Dispatcher (which in fact uses pipes under 
the hood).

Chris.