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

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-19 16:58:47

On Monday 19 February 2007 04:02 pm, Timmo Stange wrote:
> Gottlob Frege wrote:
> > I think the strong guarantee is much more important.  If I say
> > disconnect() I really don't expect calls after that.  The deadlock
> > only happens when:
> >
> > 1. signals are being processed in multiple threads and
> > 2. slots are disconnecting each other
> >
> > 1 is not what I was typically thinking wrt threaded signals - I was
> > more thinking about connect/disconnect from multiple threads, but the
> > signal would only ever happen on the same thread.  Maybe that's too
> > narrow of a view on my part.
> > 2. slots disconnecting each other is really rare/stupid
> >
>  > So I say you make the *default* disconnect wait, and supply an
>  > alternative for the rare cases.

I'm finding myself doubting the wisdom of implementing support for a strong 
disconnect guarantee.  If you do a disconnect()/block() that waits until 
the slot is finished executing, then you can deadlock on any resource that 
the slot attempts to acquire which is already held by the thread calling 
disconnect().  It doesn't necessarily require the signal to be invoked in 
multiple threads, or for two slots to attempt to simultaneously disconnect 
each other.  If someone really cares about their slot running after 
disconnect, they could always use their own mutex to lock the disconnect 
call, and also lock the mutex in the slot and check connected() before 
proceeding.

Is it really so bad to only guarantee that any signal invocations started 
after disconnect()/block() returns will not execute the slot?

-- 
Frank