2013/3/2, Robert Schroll <rschr...@gmail.com>:
> 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?
To the same place with ordinary bugs I believe (bugzilla @ gnome). But
they suggest only bugs with patches ;) Please refer to [1].
It's a little bit strange, having more and more cores in CPU and more
an more compute units in GPU but constraining the rendering only to
one thread. This is a real design bug one should think about. The
linux kernel IIRC has already for some years no BKL (big kernel lock)
anymore.
Regards,
Andrey
[1] Re: Clarification of GTK/GDK locking pre GTK 4.0
http://thread.gmane.org/gmane.comp.gnome.gtk+.general/24817/focus=24834
_______________________________________________
python-hackers-list mailing list
python-hackers-list@gnome.org
https://mail.gnome.org/mailman/listinfo/python-hackers-list
