Re: [boost] boost::signal thread safety

From: Timmo Stange (ts_at_[hidden])
Date: 2007-03-02 17:49:33

Frank Mori Hess wrote:

> The design decision that I'm most doubtful about is the explicit lock() of 
> tracked objects in the slot class.  Peter Dimov suggested an alternative 
> of having a slot throw a bad_weak_ptr exception when called with an 
> expired tracked object.  This has the advantage of allowing one slot to be 
> bound to another with boost::bind seamlessly, without requiring explicit 
> setup of tracking between the slots.  Unfortunately, throwing exceptions 
> would require changes to the combiner interface.  The most minimal change 
> I can see would be requiring combiners to take into account the 
> possibility of a slot iterator dereference throwing a bad_weak_ptr 
> exception.  This actually doesn't seem too bad.  The combiner would just 
> need to move on to the next slot if it catches an exception.

For clarification: the alternative tracking method we discussed simply
relies on shared_ptr. A slot's connection state would depend on the
reference count of the shared_ptr, which can be checked by holding a
weak_ptr to the tracked object. The mentioned lock() is
shared_ptr::lock() accordingly, which is used to both check and
guarantee the tracked object's lifetime for the duration of a call.

The fact why the combiner would need to handle bad_weak_ptr exceptions
with this idea may not be so obvious either: The signal (or the
slot_call_iterator) cannot simply swallow the exception, as the com-
biner expects a value when dereferencing the iterator and that's
not possible to guarantee when the expired slot happens to be the
last callable slot of the signal (is effectively the end(), but
not until the combiner tries to dereference it). For completeness
I'd like to add that Peter would have preferred to drop the
combiner/slot_call_iterator design, too, so that problem would
not exist.

I don't like this idea, because it effectively means dropping tracking
altogether. The original idea is not to call a slot when a tracked
object expired. This change would just put the burden on the client
code and rely on exception safe slot implementations while silently 
swallowing the bad_weak_ptr exceptions. It's non-functionality, as
the users can do something like this in any case, if they do not
want to rely on Signal's tracking.

Regards

Timmo Stange