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

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-19 02:35:10

On Monday 19 February 2007 01:42 am, Timmo Stange 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.

-- 
Frank