On Fri, 11 Feb 2005 09:46:41 +0200, Olexiy Avramchenko
<[EMAIL PROTECTED]> wrote:
> Stefan Kost wrote:
> > hi hi,
> Hello
> > I have a gobject property that is set (via g_object_set()) from within a
> > thread and from the main thread.
> > Further I have signal handlers that watch this via notify::property.
> > These signal handler call gtk functions. Therefore in these signal
> > handlers the gtk part is wrapped with gdk_threads_enter/leave().
> Wrong. GTK signal handlers run from main loop which is protected
> (gdk_threads_enter() before gtk_main() call). So you never should place
> locks inside signal handlers. You have to protect any call from *another
> thread* that uses GDK/GTK functions or data.
Hmmm, there seems to be some confusion in this area... signal callbacks
do not run directly from the mainloop, and if its a signal that you're getting
from a Gtk object, you can assume that you already have the gdk_threads_mutex
locked (or at least that /should/ be the case).
When the mainloop runs, the mainloop holds the mutex for a short time, and
unlocks the mutex while executing source callbacks (GSource; i.e. idle
functions,
timeouts & IO channel watches).
OTOH, when you call a function in the gtk+ api, example
gtk_toggle_button_set_active(), once this function returns; all callbacks
registered to the "toggle" signal for that toggle button will have already
ran (i.e. there execution in *not* defered to the main loop).
So, signals are a result of an access to a GObject, if that GObject is
a GtkWidget, then the calling code segment should already have protected
that call with the gdk_threads_mutex, so essentialy; in signal callbacks you
already have the lock, and in GSource callbacks, you need to aquire it yourself.
I hope that clears things up a bit ;-)
Cheers,
-Tristan
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
