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

Gottlob Frege wrote:

On 2/19/07, Peter Dimov 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.