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