Gottlob Frege wrote:
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.
I think avoiding potential deadlocks is equally important to the strong disconnection guarantee. The most prominent aspect of Signals is the decoupling between caller and callee it provides. The signal knows nothing about the code it calls and - through generalized callbacks - the called code doesn't even need to know it is called by a signal. We cannot expect from a user that they will carefully steer around potential deadlock problems as that would defeat most of the advantages of using the system in the first place. It's quite possible a user has no control at all over the slot code, for example. On a side note: I don't know if you've followed the tracking functionality changes we've discussed. In a nutshell, we agreed that shared_ptr/weak_ptr is the most portable, useful solution in a multi-threaded environment. Since this kind of tracking ensures the lifetime of the tracked objects during a slot call, a weak disconnect would not keep users from safely releasing resources associated with a slot - as long as they're tracked.
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?
I don't think I understood this. You can only connect a slot once - if you connect it twice it will be a separate connection and the slot will be called twice. You can only disconnect it once accordingly, although trying to disconnect it several times won't do any harm. Regards Timmo Stange