Re: Adding custom GDK events

[Chris Vine <chris cvine freeserve co uk>]

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.

Chris