Author gvanrossum
Recipients Justin Mayfield, gvanrossum, thehesiod, vstinner, yselivanov
Date 2015-11-12.01:47:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJ++w4+dzZr60jvQTiWoUvxntaFH1n17gN5V2cjFu5pnww@mail.gmail.com>
In-reply-to <1447291075.69.0.654223306017.issue25593@psf.upfronthosting.co.za>
Content
Justin's repro provides a clue: when the event loop is stopped before all
callbacks have been processed, when the loop is restarted the I/O selector
is asked again to do its work, and it will report all the same sockets as
ready. So then the callback will be put into the ready queue again (even
though it's already there). Then the second call will find the future
already done.

I'm not sure how this explains Alexander's issue but it's probably
something similar. We should carefully review the other I/O callbacks too
-- most of them look like they don't mind being called spuriously, but
there are a few others (_sock_recv, _sock_sendall, _sock_accept) that look
like they check for fut.cancelled() and might be susceptible to the same
bug.
History
Date User Action Args
2015-11-12 01:47:23gvanrossumsetrecipients: + gvanrossum, vstinner, yselivanov, thehesiod, Justin Mayfield
2015-11-12 01:47:23gvanrossumlinkissue25593 messages
2015-11-12 01:47:22gvanrossumcreate