On Feb 6, 2007, at 3:09 PM, Timmo Stange wrote:
Doug Gregor wrote:
Storing the combining in an Any was a dumb idea :)
Still, you will probably need to keep the combiner on the heap somehow, because if a slot deletes the signal object, you don't want to crash. This could happen in a GUI system, for example, in a "button pressed" event on a "cancel" button, which deletes the dialog holding the "cancel" button.
For the thread-safe implementation we will also need to keep the signal's mutex alive for that case, so I was thinking of using the impl shared_ptr (although I'm afraid of too many atomic reference count adjustments being involved in every signal invocation). Ensuring the combiner simultaneously would bring us back to square one with storing it in the base class (as an Any eventually).
Not necessarily. One could have a "signal_impl_with_combiner" template that derives from "signal_impl", and stores the combiner. Most of the shared code will still be in signal_impl, of course.
I don't think the current implementation allows deletion of the signal from a slot, btw. The signalN::combiner() function returns a reference to the stored combiner, not a copy of it. How about simply copying it in operator(), as being CopyConstructable is a precondition for the combiner anyway?
When we invoke a signal via operator(), operator() will create an instance of boost::signals::detail::call_notification that will live throughout the invocation. Among other things, this call_notification object holds a shared_ptr to the impl (which contains the combiner). Even if the "signal" object is destroyed, that shared_ptr will keep alive all of the data for the signal (including the combiner) so that the invocation can still return properly. Cheers, Doug