Re: [Boost-users] [signals] signal-signal connections and thread-safety

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-10 19:33:54

Frank Mori Hess wrote:

>> I think I might have found a solution, if not a particularly beautiful
>> one: With "signal for a slot" being handled as a special case anyway,
>> I can create a "counterfeit copy" of the signal with the original
>> signal object controlling the state and the counterfeit just sharing
>> the implementation. When the original copy goes out of scope, all
>> slots will be disconnected. The rest can be handled with some additional
>> functionality in the tracking code.
> 
> If the signal is implemented with a pimpl via a shared_ptr, couldn't 
> boost::track just store a weak_ptr to the pimpl in the special case of a 
> signal argument?  The signal could invoke the the boost::tracked by using 
> the get_pointer() function and invoking it as a pointer to a function 
> object (assuming the pimpl provides an operator() member function).  Is 
> that is what you are already suggesting?

Our influence on slot target storage and invocation is limited, as
the client tells us what container type to use through a template
parameter (SlotFunction). I would prefer to store a normal function
object there instead of trying to trick it into invoking the object
through a pointer and still getting the argument binding right. That's
why I'd rather use a copy of the full signal object instead of its
pointer to implementation. We can be sure that everything will work
as expected, no matter what type SlotFunction is.

The tracking will then need extra functionality to identify signal
targets that have been disconnected, but I think that's easier to
achieve, because we are in control of all the types involved.

Regards

Timmo Stange