Re: Adding custom GDK events
- From: Chris Vine <chris cvine freeserve co uk>
- To: gtkmm-list gnome org
- Cc: Daniel Elstner <daniel kitta googlemail com>, Doron Singer <antrax gmail com>
- Subject: Re: Adding custom GDK events
- Date: Sun, 14 Jan 2007 00:36:09 +0000
On Friday 12 January 2007 01:20, Daniel Elstner wrote:
> Am Freitag, den 12.01.2007, 00:23 +0000 schrieb Chris Vine:
> > With Glib::signal_idle() you have to reconnect the slot every time you
> > want it to fire (and make sure you return false). With Glib::Dispatcher
> > you just call emit on it (it is in effect a thread safe version of
> > sigc::signal0<void>). Glib::signal_idle() is more convenient if you want
> > to pass different data on each invocation, because you can do that by
> > binding to the slot. You should only emit Glib::Dispatcher from a
> > different thread from the main GUI thread. Glib::signal_idle() is thread
> > safe and can be called from the main GUI thread or any other thread.
> Oh sh*t. If I had only known that Glib::signal_idle() was thread-safe,
> I might never have started working on Glib::Dispatcher :-)
> It does have the advantage though that it's memory allocation-free once
> set up.
It has the advantage of being much more efficient, since emitting the signal
only requires writing a few bytes to a pipe, rather than creating new slots.
The main problem with Dispatcher is that if you try to emit from the main
(GUI) thread, you risk a deadlock (if the pipe happens to be full the write
will block and where the emitting thread is the main loop thread which also
does the read, will never unblock). I have my own Dispatcher-like class
which detects this condition and will invoke the connected slot directly
rather than via the pipe when this occurs. It also detects if, between the
dispatcher being emitted and the main loop executing the slot (an
indeterminate period of time), the Dispatcher object has ceased to exist, but
that is a much less significant issue.
] [Thread Prev