Re: [Boost-users] [signals] thread_safe_signals feature-complete

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-02-19 21:29:45

Gottlob Frege wrote:
> On 2/19/07, Peter Dimov <pdimov_at_[hidden]> wrote:
>> Gottlob Frege wrote:
>>
>>> - one of the original reasons (in my head at least) for blocking on
>>> disconnect() is so that you can disconnect() in your destructor (and
>>> thus avoid having a dead object being called).
>>
>> But then you need to deal with the possibility that a call can
>> already be in progress at the time your destructor is invoked. (If
>> you can guarantee that this cannot happen, it seems to me that you
>> can also guarantee that a call isn't started after the disconnect.)
>> So let's assume that you lock the object mutex. There's still the
>> nasty scenario where:
>>
>> ~X locks the object mutex
>> X::f is called by the signal and blocks on the object mutex
>> ~X disconnects and destroys *this, including the object mutex
>> X::f crashes and burns
>>
>> I can't think of a way to avoid the above that doesn't also solve
>> the "call after disconnect" problem.
>>
>
> using weak_ptrs (I think you've heard of them? :-).

Rings a bell. But using weak_ptr's also makes the "no calls after 
disconnect" guarantee unnecessary; the signal will take proper care of your 
object's lifetime by keeping a shared_ptr to it during the call. So why 
provide it? Seems to me that you can't (easily) take advantage of it safely.