glibmm thread safety [was: Re: Adding custom GDK events]

[Daniel Elstner <daniel kitta googlemail com>]

Am Sonntag, den 14.01.2007, 00:36 +0000 schrieb Chris Vine:
> >
> > 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.

Not to mention that there is no extra locking, apart from whatever the
write() system call does.  Hmm, it would be interesting to profile the
performance of Glib::Dispatcher and Glib::signal_idle() and compare the
results.

> 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).

Oh OK, I think that is one for the docs.  Talking to yourself results in
a deadlock -- heh, one could almost make a running gag out of that.

> 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.

Can't imagine why one would need that.  But then again, you probably
have some pretty good reason if you went as far as creating your own
Dispatcher class.

> 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.

Hmm, this one is actually more interesting to me.  I reckon this
situation could only occur if if a receiving thread instantiated more
than one Dispatcher object, right?  Because otherwise the pipe() should
have been closed already.  The safe route seems to be to make sure that
the Dispatcher objects live as least as long as the main loop runs.
Alternatively, have the receiving thread wait for some token that
signals the very last invocation of the Dispatcher slot.

--Daniel