Re: Application suddenly stuck at startup

[Andrey Gursky <andrey gursky e-mail ua>]

Hi Robert, Jonathan,

2013/3/1, Robert Schroll <rschroll gmail com>:
> On Fri, Mar 1, 2013 at 12:46 PM, Jonathan Ballet <jon multani info>
> wrote:
> > On 03/01/2013 03:11 PM, Robert Schroll wrote:
> > > On Fri, Mar 1, 2013 at 10:12 AM, Jonathan Ballet <jon multani info>
> > > wrote:
> > > > I notice that either:
> > > >   * removing the loop with Gtk.main_iteration(), or...
> > > >   * removing the "Gdk.threads_init()" call
> > > > doesn't exhibit the problem.
> > > I think the problem is that you don't have the Gdk lock when you're
> > > calling Gtk.main_iteration, which is a bad thing.  If you take out
> > > Gdk.threads_init, the main thread will never give up the lock, so
> > > your
> > > callback will be guaranteed to run inside of it.  If you don't need
> > > to
> > > do Gtk stuff from other threads, this is probably the way to go.
> > As I understand [1], I don't have to call Gdk.threads_enter() /
> > Gdk.threads_leave() if I'm within a signal handler, such as the one
> > from my example I would say.
>
> 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!

> 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.

Regards,
Andrey