Re: [Boost-users] [signals] Automatic connection management and MT

From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-02-06 15:18:26

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