Re: deprecating gdk threads
- From: Paul Davis <paul linuxaudiosystems com>
- To: Pavel Holejsovsky <pavel holejsovsky gmail com>
- Cc: gtk-devel-list gnome org
- Subject: Re: deprecating gdk threads
- Date: Mon, 6 Aug 2012 13:38:25 -0400
On Mon, Aug 6, 2012 at 1:28 PM, Pavel Holejsovsky
<pavel holejsovsky gmail com> wrote:
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.
the title of this thread is "deprecating GDK threads".
nothing stops anyone from using other mechanisms (including those in glib) to handle synchronization. the issue is whether or not GDK has an explicit multithreaded model, not whether or not other users of gobject + signals can use threads (they can, as ever).
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]