Re: Application suddenly stuck at startup

2013/3/2, Robert Schroll <rschroll gmail com>:
On Fri, Mar 1, 2013 at 7:14 PM, Andrey Gursky <andrey gursky e-mail ua>
Hi Robert, Jonathan,

2013/3/1, Robert Schroll <rschroll 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,
 GtkApplication.  It could be that GLib signal handlers run outside
 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)


[1] Re: Clarification of GTK/GDK locking pre GTK 4.0

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]