On Monday 19 February 2007 04:02 pm, Timmo Stange wrote:
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'm finding myself doubting the wisdom of implementing support for a strong disconnect guarantee. If you do a disconnect()/block() that waits until the slot is finished executing, then you can deadlock on any resource that the slot attempts to acquire which is already held by the thread calling disconnect(). It doesn't necessarily require the signal to be invoked in multiple threads, or for two slots to attempt to simultaneously disconnect each other. If someone really cares about their slot running after disconnect, they could always use their own mutex to lock the disconnect call, and also lock the mutex in the slot and check connected() before proceeding. Is it really so bad to only guarantee that any signal invocations started after disconnect()/block() returns will not execute the slot? -- Frank