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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-19 02:55:40

Frank Mori Hess wrote:

>> What I don't like about the release of all mutexes during the call
>> is that we lose the strong semantics of disconnect() and block().
>> We cannot guarantee anymore, that a slot won't be called after
>> disconnect() returned. That is a form of thread safety only the
>> library can provide.
> 
> We could have the connection body dispense some kind of reference-counted 
> token.  The slot iterator would grab a copy of the token when it has 
> iterated onto a slot that it might execute, and destroy it when it 
> iterates past the slot or destructs.  disconnect()/block() could check the 
> reference count to decide when it is safe to return, either spinning or 
> waiting on a condition variable in the meantime.  Since we only want the 
> disconnect() to wait if the slot is running in a different thread, the 
> token would have to maintain both a global and a thread-specific reference 
> count.  disconnect()/block() could return when they are equal.

If you don't let disconnect() return until all calls to the slot are
through, you're back to square one with regard to potential deadlocks.
Keep in mind that disconnect() may be called (in practice often is)
from a slot call context.

I don't think there is a clean solution to this which covers all
problems. It would be possible to have different threading policies
for either behavior (one being dead-lock-safe, the other with
strong disconnect() guarantees), but that defeats the whole
abstraction idea. Alternatively, disconnect() could return a bool
if the disconnected slot is currently running or throw an exception.
That could be optional through an argument (disconnect(true)) or
a different function (checked_disconnect()). A connection::wait()
function could wait for all pending calls to finish, but couldn't
be safely called from a signal invocation context.

Regards

Timmo Stange