Re: Application suddenly stuck at startup

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

2013/3/2, 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?

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