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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-10 01:48:26

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.

The series of problems does not end, though ;). Now I have a problem
with understanding this in the original code:

template<typename T>
void maybe_get_pointer(const T& t, mpl::bool_<false>) const
{
   // Take the address of this object, because the object
   // itself may be trackable
   add_if_trackable(boost::addressof(t));
}

If I'm not mistaken, this takes the address of an object stored by value
in the target function object and adds it to the list of tracked objects
if it's derived from trackable. What I don't understand is how that is
supposed to work. If not provided by reference, the visitor is run over
a temporary target function object passed by the client when connecting
or creating the slot. It is copied after that by the Function object
by default. The tracked object will then be destroyed together with
the temporary function object and the slot will be disconnected.

The trackable_test.cpp only checks a case in which a pointer to
trackable is bound to the function. So is this a bug or am I missing
something?

Regards

Timmo Stange