Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The proactor event loop has a race condition when reading with pausing/resuming. `resume_reading()` unconditionally schedules the read function to read from the current future. If `resume_reading()` was called before the previously scheduled done callback fires, this results in two attempts to get the data from the most recent read and an assertion failure. This commit tracks whether or not `resume_reading` needs to reschedule the callback to restart the loop, preventing a second attempt to read the data.
|
@asvetlov Andrew, can you take a look? |
|
Looks OK to my eyes. |
|
I noticed that the first run of test_asyncio on appveyor failed, but the rerun with -v succeeded. I've been unable to reproduce that failure locally, and I'm not seeing anything I missed, so I'm not sure what might be the problem. Are there any known issues with test_asyncio? |
|
@asvetlov: Please replace |
|
thanks! |
|
GH-7004 is a backport of this pull request to the 3.7 branch. |
The proactor event loop has a race condition when reading with pausing/resuming. `resume_reading()` unconditionally schedules the read function to read from the current future. If `resume_reading()` was called before the previously scheduled done callback fires, this results in two attempts to get the data from the most recent read and an assertion failure. This commit tracks whether or not `resume_reading` needs to reschedule the callback to restart the loop, preventing a second attempt to read the data. (cherry picked from commit 4151061) Co-authored-by: CtrlZvi <viz+github@flippedperspective.com>
|
Sorry, @CtrlZvi and @asvetlov, I could not cleanly backport this to |
The proactor event loop has a race condition when reading with pausing/resuming. `resume_reading()` unconditionally schedules the read function to read from the current future. If `resume_reading()` was called before the previously scheduled done callback fires, this results in two attempts to get the data from the most recent read and an assertion failure. This commit tracks whether or not `resume_reading` needs to reschedule the callback to restart the loop, preventing a second attempt to read the data. (cherry picked from commit 4151061) Co-authored-by: CtrlZvi <viz+github@flippedperspective.com>
|
@CtrlZvi 3.6 branch is quite different from 3.7/master. |
|
I will take a look! |
The proactor event loop has a race condition when reading with pausing/resuming. `resume_reading()` unconditionally schedules the read function to read from the current future. If `resume_reading()` was called before the previously scheduled done callback fires, this results in two attempts to get the data from the most recent read and an assertion failure. This commit tracks whether or not `resume_reading` needs to reschedule the callback to restart the loop, preventing a second attempt to read the data.. (cherry picked from commit 4151061) Co-authored-by: CtrlZvi <viz+github@flippedperspective.com>
|
GH-7110 is a backport of this pull request to the 3.6 branch. |
) The proactor event loop has a race condition when reading with pausing/resuming. `resume_reading()` unconditionally schedules the read function to read from the current future. If `resume_reading()` was called before the previously scheduled done callback fires, this results in two attempts to get the data from the most recent read and an assertion failure. This commit tracks whether or not `resume_reading` needs to reschedule the callback to restart the loop, preventing a second attempt to read the data.. (cherry picked from commit 4151061) Co-authored-by: CtrlZvi <viz+github@flippedperspective.com>
The proactor event loop has a race condition when reading with pausing/resuming. `resume_reading()` unconditionally schedules the read function to read from the current future. If `resume_reading()` was called before the previously scheduled done callback fires, this results in two attempts to get the data from the most recent read and an assertion failure. This commit tracks whether or not `resume_reading` needs to reschedule the callback to restart the loop, preventing a second attempt to read the data.
The proactor event loop has a race condition when reading with
pausing/resuming.
resume_reading()unconditionally schedules the readfunction to read from the current future. If
resume_reading()wascalled before the previously scheduled done callback fires, this results
in two attempts to get the data from the most recent read and an
assertion failure. This commit tracks whether or not
resume_readingneeds to reschedule the callback to restart the loop, preventing a
second attempt to read the data.
https://bugs.python.org/issue26819