This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason
Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality
A bit unfortunate that we had to add a 10 msec delay here -- in most cases that will waste 10 msec and occasionally it will not wait long enough and the test will flake-fail. Why won't call_soon work?
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason
Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality
Background: this test covers a bug that base exceptions like KeyboardInterrupt will cause the loop to be closed twice, leading to an early exit in the next loop run.
This test was added before _StopError was dropped, at that time the loop will stop as soon as _StopError is raised, even if the _ready queue still has a handle (which is the next run - the func() here), therefore this was a good test. But now the loop will exhaust the _ready queue before stopping, so this test couldn't cover the bug anymore without this PR. That's also why we cannot simply add func() into the _ready queue by call_soon().
You're right about the flakyness of using call_later() tho. Now I think a better fix would be to use chained call_soon() to skip the first iteration where the buggy stop occured:
Suggested change
self.loop.call_later(0.01, func)
# If the issue persists, the loop will exit early after the first iteration,
# in that case our func() in the second iteration won't be called.
self.loop.call_soon(self.loop.call_soon, func)
I verified and this error fails if the fix in f3e2e09 is reverted.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityA bit unfortunate that we had to add a 10 msec delay here -- in most cases that will waste 10 msec and occasionally it will not wait long enough and the test will flake-fail. Why won't call_soon work?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityBackground: this test covers a bug that base exceptions like KeyboardInterrupt will cause the loop to be closed twice, leading to an early exit in the next loop run.
This test was added before _StopError was dropped, at that time the loop will stop as soon as _StopError is raised, even if the _ready queue still has a handle (which is the next run - the func() here), therefore this was a good test. But now the loop will exhaust the _ready queue before stopping, so this test couldn't cover the bug anymore without this PR. That's also why we cannot simply add func() into the _ready queue by call_soon().
You're right about the flakyness of using call_later() tho. Now I think a better fix would be to use chained call_soon() to skip the first iteration where the buggy stop occured:
I verified and this error fails if the fix in f3e2e09 is reverted.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityClever solution, go ahead and make it a PR, assign to me or @kumaraditya303 for review.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.