Re: [Boost-users] [signals] per slot mutexes

From: Timmo Stange (ts_at_[hidden])
Date: 2007-03-01 17:06:01

Frank Mori Hess wrote:

> I've got thread_safe_signals working with a single mutex per signal, which 
> is only locked/unlocked once per signal invocation.  However, it is 
> causing problems with deletion_test.cpp.  The deletion test checks if a 
> slot is able to disconnect another slot which is ordered later in the same 
> signal invocation.  From the signals docs:
> 
> "If a signal/slot connection is disconnected at any time during a signal's 
> calling sequence, the calling sequence will still continue but will not 
> invoke the disconnected slot."
> 
> When the list of blocked slots is created at the beginning of signal 
> invocation, before running any slots, then the signal invocation never 
> notices that a later slot has been disconnected by an earlier slot.  It 
> seems to me the only solutions are to either keep per-slot locking, or to 
> drop the requirement that the signal recognize changes to the connection 
> status that happen while the invocation is in progress.  I don't have a 
> good feel for how important a feature this is.  My inclination is to just 
> keep per-slot locking.

Well, that's a problem with creating a list of blocked slots and not
with locking, or? I only use a per-signal mutex and it passed (past
tense, since the current version won't compile ;)) the deletion test
fine. I don't use any cleanup or state checking on the whole list of
slots, but a reference count for each slot instead. When that count
drops to 0, the slot is finally removed from the list. The slot_
call_iterator increases the count before the call and decreases
it afterwards to ensure the iterator validity. Connecting and dis-
connecting similarly increases/decreases the count.

Regards

Timmo Stange