Re: Adding custom GDK events

[Daniel Elstner <daniel kitta googlemail com>]

Am Freitag, den 12.01.2007, 02:20 +0100 schrieb Daniel Elstner:
> 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 :-)

Now wait... are you really sure Glib::signal_idle() is thread-safe?
Connecting to a signal involves allocation of memory and writing to that
memory within the thread, which is again read on emission of the idle
slot in the main thread.  You'd have to lock around both the write and
the read.  This is easily done for the write, but impossible for the
read since by the time the idle callback is running the memory will
already have been accessed by the signal machinery.

I follow Butenhof religiously when it comes to threads.  And Butenhof
basically says this: "always protect memory accessed by multiple threads
with a mutex, even you know that chronologically the threads don't
access the memory at the same time".

--Daniel