Skip to content

bpo-26819: Prevent proactor double read on resume#6921

Merged
asvetlov merged 1 commit into
python:masterfrom
CtrlZvi:fix-bpo-26819
May 20, 2018
Merged

bpo-26819: Prevent proactor double read on resume#6921
asvetlov merged 1 commit into
python:masterfrom
CtrlZvi:fix-bpo-26819

Conversation

@CtrlZvi

@CtrlZvi CtrlZvi commented May 16, 2018

Copy link
Copy Markdown
Contributor

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.

https://bugs.python.org/issue26819

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.
@1st1

1st1 commented May 17, 2018

Copy link
Copy Markdown
Member

@asvetlov Andrew, can you take a look?

@1st1

1st1 commented May 17, 2018

Copy link
Copy Markdown
Member

Looks OK to my eyes.

@CtrlZvi

CtrlZvi commented May 19, 2018

Copy link
Copy Markdown
Contributor Author

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 asvetlov merged commit 4151061 into python:master May 20, 2018
@miss-islington

Copy link
Copy Markdown
Contributor

Thanks @CtrlZvi for the PR, and @asvetlov for merging it 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7.
🐍🍒⛏🤖

@bedevere-bot

Copy link
Copy Markdown

@asvetlov: Please replace # with GH- in the commit message next time. Thanks!

@asvetlov

Copy link
Copy Markdown
Contributor

thanks!

@bedevere-bot

Copy link
Copy Markdown

GH-7004 is a backport of this pull request to the 3.7 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 20, 2018
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>
@miss-islington

Copy link
Copy Markdown
Contributor

Sorry, @CtrlZvi and @asvetlov, I could not cleanly backport this to 3.6 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 4151061855b571bf8a7579daa7875b8e243057b9 3.6

miss-islington added a commit that referenced this pull request May 20, 2018
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>
@asvetlov

Copy link
Copy Markdown
Contributor

@CtrlZvi 3.6 branch is quite different from 3.7/master.
Could you backport the change by hands?

@CtrlZvi

CtrlZvi commented May 20, 2018

Copy link
Copy Markdown
Contributor Author

I will take a look!

CtrlZvi added a commit to CtrlZvi/cpython that referenced this pull request May 22, 2018
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>
@bedevere-bot

Copy link
Copy Markdown

GH-7110 is a backport of this pull request to the 3.6 branch.

asvetlov pushed a commit that referenced this pull request May 25, 2018
)

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants