Re: deprecating gdk threads

[Pavel Holejsovsky <pavel holejsovsky gmail com>]

On Mon, 06 Aug 2012 11:56:48 -0400, Paul Davis wrote:

> i don't believe that there are any examples in glib/gdk/gtk where a
> signal handler attached to a signal of a glib/gdk/gtk object will be
> executed in anything other than the main event loop. glib/gdk/gtk
> doesn't contain any "thread tunneling" for signal handler dispatch, so
> the handler is always executed in the same thread that the signal is
> "emitted" from.

This is true for glib/gdk/gtk.  But you will get signals from worker 
threads when you are working with gstreamer.  And AFAIK you will get 
callbacks from worker threads when using asynchronous Gio operations.

> but its not clear that glib/gdk/gtk should be trying to help with that
> situation.

Well, even if glib/gdk/gtk/clutter chooses to ignore integration with 
gstreamer, it definitely should play nice with gio.  So I think the issue 
cannot be dismissed that lightly.

> AFAIU, it never needs to be used for threading purposes inside a handler
> of a normal GTK's widgets signals. it does need to be used when you are
> dealing with a condition that actually requires interacting with GTK
> widget state - in this case, the thread that detects the condition via
> some private mechanism unknown to the main event loop needs to use
> idle_add() to get the main event loop to run the GTK-related code.

Yes, thats exactly the case.  And that 'thread that detects the condition 
via some private mechanism unknown to the main event loop' can happen to 
be executing _finish() callback from gio, so it is pretty mainstream 
thing, not just some obscure application-specific mechanism.

pavel