Re: [boost] boost::signal thread safety

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-03-03 11:38:02

Timmo Stange wrote:

> I don't like this idea, because it effectively means dropping tracking
> altogether. 

You must be referring to the fact that you can't detect an expired slot
until it is invoked (a fact that slipped my mind).  I'll have it both ways
then: keep the explicit slot-to-slot tracking, but also make
slot::operator() throw on an expired slot, and make last_value handle
exceptions thrown by expired slot exceptions.  The signal would still do an
explicit lock() on the slot, and call it through a slot::unlocked_call()
which doesn't bother checking the tracked objects.  Then, the disconnect on
exception would handle cases where the user hasn't explicitly tracked the
slot, due to automatic disconnection on invocation being good enough and
not wanting to keep track of slots hidden inside other function objects.

> ... while silently 
> swallowing the bad_weak_ptr exceptions. 

I don't have any problem with throwing a more specialized exception.  To be
really paranoid, it could even have a private constructor to discourage the
user from reusing it for other purposes.  I probably wouldn't do that
though, as I don't see a problem with letting the user deliberately trigger
the signal's slot disconnection mechanism if they choose to.

-- 
Frank