On Sat, 14 Apr 2012 22:33:02 +0100, Andrew Suffield <asuffi...@suffields.me.uk> wrote: > 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?
By checking the return value of disconnect(). > 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. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
