Re: Application suddenly stuck at startup

On Fri, Mar 1, 2013 at 7:14 PM, Andrey Gursky <andrey gursky e-mail ua> wrote:
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, 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,

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