On Fri, Mar 1, 2013 at 7:14 PM, Andrey Gursky <andrey.gur...@e-mail.ua>
wrote:
Hi Robert, Jonathan,
2013/3/1, Robert Schroll <rschr...@gmail.com>: I agree with your
reading of the docs. It's things like this that
leave me perpetually confused about threading. The one possible
explanation I see is that "activate" is a signal of GApplication,
not
GtkApplication. It could be that GLib signal handlers run outside
of
the Gdk lock, while Gtk signal handlers run inside.
Hopefully someone who actually understands all of this will comment.
Robert, you're right regarding GLib vs GTK callbacks!
Thanks for straightening me out! Every time I look at GTK threading,
I think I learn one thing about it. In another few decades, I hope to
understand it completely!
From GDK doc mentioned before:
Idles, timeouts, and input functions from GLib, such as
g_idle_add(), are executed outside >of the main GTK+ lock. So, if
you need to call GTK+ inside of such a callback, you must >surround
the callback with a gdk_threads_enter()/gdk_threads_leave() pair or
use >gdk_threads_add_idle_full() which does this for you. However,
event dispatching from the >mainloop is still executed within the
main GTK+ lock, so callback functions connected to >event signals
like GtkWidget::button-press-event, do not need thread protection.
In GTK+ callbacks the GTK+-lock is acquired automatically, in GLib of
course that's not the case.
It's logical when you think about how the implementation must work.
But from that particular paragraph, it's not at all clear that a GLib
signal handler belongs in the class of "idles, timeouts, and input
functions from GLib," rather than the class of "callback functions
connected to event signals like GtkWidget::button-press-event." Is
there some place to submit bugs against the documentation?
Thanks again,
Robert
_______________________________________________
python-hackers-list mailing list
python-hackers-list@gnome.org
https://mail.gnome.org/mailman/listinfo/python-hackers-list
