Re: [boost] [Signals] Recursive callback design questions, including socket multiplexor implementation example

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

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.

        Doug