From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-06-22 12:00:43
On May 13, 2005, at 4:05 PM, Cliff Green wrote:
> The design issue is that modifying the callback container from within
> the callback invocation (i.e. calling "registerIncomingMsgCallback")
> requires some tricky guarding and managing of the internal callback
> container. In effect, register and unregister requests are placed on a
> queue, and then applied when events (messages) are not causing the
> callbacks to be invoked.
> I've found that I've duplicated this code in multiple places
> (primarily because there are multiple types of callbacks - e.g.
> incoming msg callbacks, outgoing msg callbacks, connection monitoring
> callbacks, periodic invocation callbacks, etc). This is Not Good, and
> not yet) generic.
> Does Boost.Signals directly address this type of use case? I've read
> the tutorial and examples many times, and it's still not clear to me
> if it does (that may be due to my understanding versus the
> documentation itself). Is the trackable functionality meant to address
> this type of use? If not, has this kind of usage been considered as
> relevant or desirable for Signals? I'm willing to help enhance, within
> the constraints of my available time.
Wow, you posted this a long time ago; my apologies for the delay, I'd
marked it as important and then forgotten it completely.
Signals is designed to handle this use case and you're right: it's
tricky. You can have a signal call a slot that calls the same signal
that calls some slots that add/remove slots from the signal, and that's
perfectly fine. We don't queue requests (because the request could come
from a slot that's been deleted, so we absolutely must not call it),
but rather mark slots as "removed" and do cleanups when there are no
more outstanding signal invocations. Take a look at the
"random_signal_system.cpp" torture test in libs/signals/test, where it
does lots of random, recursive signal invocations that disconnect
This actually doesn't have much to do with "trackable" in Signals;
trackable just handles automatically disconnecting slots when one of
the objects involved in the slot dies.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk