On Thursday 01 March 2007 05:06 pm, Timmo Stange wrote:
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.
That would seem to require some kind of locking, or atomic operations to increment/decrement the reference counts safely? I was only trying to get rid of per-slot locking to reduce locking overhead. -- Frank