>Looking at the code of GtkRadioButton, I have to question whether it's
>thread safe. I don't use threads (yet) in my application... and
No part of GTK or any X Window toolkit is thread-safe *by
default*. You can either choose to use explicit locking functions
provided by GTK, or you can ensure that all GTK ops are performed in a
single thread. I and (it appears) most other people with experience of
multithread GTK apps prefer the latter approach. You set up a
notification system (typically using a FIFO) that signals the GUI
thread that some work needs to be done. Other threads make absolutely
no calls to GTK or GDK or X functions.
>I'm wondering this because I see some operations being performed on a
>GSlist in the widget's code, and I don't see any locking taking place.
Terrible idea. That should not happen. If it does, you need to
redesign your program.
Just for completeness: the reason that X Window works this way is that
any GUI toolkit is faced with a dilemma about thread support:
* be thread-safe, but slow down the common case (single-threaded programs)
* be thread-unsafe, and create more work for programmers working
on multithreaded programs
X Window chose the latter option. Some other systems (such as the ones
typically used on Windows) chose the former.
--p
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
