Gottlob Frege wrote:
- do you hold any locks DURING the slot call? That's typically bad, since you have no idea what else is locked or what a slot might do, so deadlocks abound.
Yes, that is a problem both implementations have right now.
- do you copy the slot list before running through the list?
Frank's approach has copy-on-write semantics.
- can I connect/disconnect during my slot call (either disconnect myself, or connect/disconnect other calls? If so, does it happen in this signal, or the next one?)
You can do that in both implementations. The behaviour regarding connect()s from a slot context differs. Disconnections always work for the current call, as long as the slot wasn't already passed.
- as for the 'lock per slot' vs 'lock per signal': The solution I've come up with in the past is basically lock per slot, but more importantly *temporary* lock per slot. ie you create (or take from a pool) locks as needed, and store them in a "slot -> lock" map, so IF another thread also needs the lock for that slot, they check the map first, and obtain the same lock for that slot. Using this, if you are careful, in most cases, you don't actually end up creating the lock at all (as you have all the information necessary to see contention as it is happening, and create the locks as needed. ie you know which slot is being called, and which slot is concurrently being disconnected, and only lock if they are the same - which means don't lock on the slot call, but AFTER the call, see if another thread has come in and is waiting for you to finish. So actually it is not a lock at all, but more of an 'event' (or a 'signal' but that'd be confusing).
I'm not sure I completely understood what you're suggesting here. Trying to avoid the use of the synchronization primitives we have (few as they are with Boost.Threads) will most likely lead to trouble. The lock map you're proposing would need to be synched with a mutex, too, so I don't see the immediate gain. I currently only use a per-signal mutex and it should be possible to release that for the duration of the slot call to avoid the deadlocks you mentioned further above. That doesn't give me the freedom of concurrent slot invocation, but seeing how many problems that entails, I'm not sure it is worth the trouble anymore. Regards Timmo Stang