Re: Application suddenly stuck at startup

[Robert Schroll <rschroll gmail com>]

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,
Robert