[PyQt] Signals arriving after proxy slots deleted
Phil Thompson
phil at riverbankcomputing.com
Sun Apr 15 11:45:02 BST 2012
On Sat, 14 Apr 2012 22:33:02 +0100, Andrew Suffield
<asuffield at 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
More information about the PyQt
mailing list