On Sat, Apr 14, 2012 at 03:14:28PM +0100, Phil Thompson wrote: > Once the C++ disconnect() has completed then it shouldn't matter if the > proxy is still around or not. Has the disconnect() actually succeeded?
Hmm, interesting question. How do I tell? I should note that it's difficult to test because this is a race condition which occurs infrequently - one of these pops up somewhere between 1/10 and 1/100 of the time. Also, the signals are always arriving via sendPostedEvents - this is always cross-thread stuff. The object with the slot always lives in the QThread where it was created, so I assume that QNetworkAccessManager has its own worker threads and is posting the signals from there. Presumably the signal was emitted before the disconnect() and arrived as soon as control passed back to the event loop, but that's speculation. Since (as far as I understand it) with the C++ Qt interface you are supposed to be able to disconnect a slot and then immediately delete its object, there must be something in Qt which ensures posted events don't get delivered for disconnected slots. Perhaps it has been broken somehow? Bit of a head-scratcher really - I can see this isn't supposed to break, so something somewhere is wrong. Unfortunately that means pyqt, qt, and all of my own code are in scope as possible culprits. _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
