From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-01-29 14:43:17
On Jan 10, 2007, at 3:23 PM, Braddock Gaskill wrote:
> I've implemented some limited thread-safe extensions to the boost
> signals library for my own use. My signal_mt, connection_mt, and
> scoped_connection_mt classes provide some basic multi-threaded
> functionality, although I certainly don't pretend they are
> particularly mature or elegant.
> For the curious, my thread-safe extensions can be found at:
Great! This is a oft-requested feature, but not one I'll be able to
address in the foreseeable future. I'm glad to see that you're
working on it!
> Included is some unit testing code which provides some usage examples
> and reasonably good code coverage (although it is not fully
Ah, good. I expect we'll need something like random_signal_system
(but multithreaded) to really bang on the implementation. That one
test caught a huge number of bugs in the handling of vertex (dis)
connections while the signal is being called.
> I was curious if experienced eyes on the list could point out any
> serious flaws or suggestions.
> A multi-threaded signal concept inherently needs to be treated with
> some care, since the slots need to be prepared to be called from any
> thread -- or, preferably, signaling should be restricted by design to
> one thread.
> A particular weakness in this implementation is that the signal
> remains (recursively) mutex locked during the iteration through
> connected slot calls.
Eric Niebler had some good ideas to eliminate the need for this lock:
> I also have not added code for more than zero,
> one, or two parameter signals -- although it is trivial to do so. I
> hoped to get some feedback first (or find more bugs before I had to
> fix each one in 10 places).
Yeah, this is a pain. Signals uses the preprocessor library to
eliminate a bunch of the redundancy, but it can still get pretty ugly.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk