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.
When the singnal is triggered from the thread it works, but when it gets
triggerd from the main thread gdk_threads_enter blocks.
Sure, expected behaviour.
This is quite obvious, as in this thread I am already in
gdk_threads_enter(). But how should the signal handler know that (wheter
it has been triggered from the main thread or from another thread)?
If I understand right you're talking about recursive muteces, but the
one used in GDK is fast - it will block when locked from the same thread
more that once.
Olexiy
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
