[Gtk-sharp-list] ThreadNotify: The saga continues

Miguel de Icaza miguel@ximian.com
25 Oct 2002 12:22:55 -0400


> I've been using Gtk# for a while now, got the usual stumbling blocks
> but ultimately everything fits together. However, I have come to
> realize something that I think is annoying from the point of view of a
> user. That is, ThreadNotify. I've used it for a while and it served
> its purpose very well for some time. When my small project got a
> little bigger and I made a little heavier use of threads for the
> different tasks, my code just started to became uglier and uglier, and
> just because I had to use ThreadNotify everytime I needed to make the
> smallest change to the widgets. 
> I was wondering if there is a plan to make the libraries thread safe,
> not in the sense of insert mutexes for everything in Gtk (something I
> think is the responsability of the user), but to allow getting the job
> done without ThreadNotify. 

The problem as you well point out is that Gtk is not thread safe, and
making it thread safe will be very complex.  In fact, Gtk is thread
aware already and has some limited support for thread, but it is very
complicated code.  It would also slow down Gtk a lot for the average

Most Gtk programs are event-driven programs.  Even driven programs are a
lot simpler to debug than multi-threaded applications.  In general, my
suggestion is to only use threads when you absolutely have to because
they bring a level of complexity that most of the time you can avoid. 
You might for instance want to read John Ousterhout's notes for his
Usenix keynote on `Why threads are a bad idea (most of the time)' or
something like that. 

Maybe you could explain what your program does, and why you need to use
so many threads?