On Mon, Aug 6, 2012 at 11:08 AM, Pavel Holejsovsky < pavel.holejsov...@gmail.com> wrote: [ ... ]
Sorry for not being clear. I wanted to say that previously, when higher > language registered callback or signal, it didn't have to bother whether > the callback or signal will be called with proper thread, because > gdk/clutter_thread_() magic worked automatically in the background. 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. now, naturally, if you manually emit a signal from some other thread, or if you have your own object with its own internal threading semantics that sometimes results in a signal being emitted from some thread other than the main event loop, then sure, all bets are off. but its not clear that glib/gdk/gtk should be trying to help with that situation. Now the application writer has to care whether the signal (or callback) > can come in some other thread and whether GLib.idle_add() is needed or not. > It is just potential source of bugs when GLib.idle_add() is not used when > it should be. 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.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
