On 2/19/07, Frank Mori Hess
Yes, I think the strong disconnect() guarantee will also guarantee the deadlock you outlined earlier with two slots attempting to disconnect each other will always be possible.
I think the strong guarantee is much more important. If I say disconnect() I really don't expect calls after that. The deadlock only happens when: 1. signals are being processed in multiple threads and 2. slots are disconnecting each other 1 is not what I was typically thinking wrt threaded signals - I was more thinking about connect/disconnect from multiple threads, but the signal would only ever happen on the same thread. Maybe that's too narrow of a view on my part. 2. slots disconnecting each other is really rare/stupid So I say you make the *default* disconnect wait, and supply an alternative for the rare cases. P.S. what about connect/disconnect 'pairing'? ie is there an assumed (or explicit) contract that every call to connect is matched by a disconnect? If I have a slot that is in a signal, and that SAME signal is triggered in, say, 3 threads, the slot can't just call disconnect() (ie the same code in each thread) - it has to somehow carefully keep track that it is calling disconnect() in 1 thread, and the other 2 threads need to skip the disconnect() call. Or does that matching guarantee not exist? - Tony