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

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-10 17:04:12

On Saturday 10 February 2007 01:48 am, Timmo Stange wrote:
> Timmo Stange wrote:
> > I've come across another problem that I find difficult to solve: Since
> > signals are not copyable, the current implementation reference-wraps
> > them when they're used as a slot target. The proper
> > lifetime-dependency is established by signals being trackable
> > subclasses, but we agreed that this won't work with thread-safe
> > signals. Our weak_ptr-based solution doesn't work well when the
> > tracked object is the actual target function object. Any suggestions?
>
> 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?

-- 
Frank