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

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-02-19 21:36:13

On 2/19/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> 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.
>

That's why I brought up the 'original reason' - it is no longer
necessary.  But there are still other times that disconnect is called,
and I was wondering how important the guarantee is for them.  I guess
I'm not being very clear.

1. review original reasons - do they still apply?
2. consider other existing reasons

Tony