GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||
GeezerVison is showing github.com — Fix an outdated test in asyncio by fantix · Pull Request #24477 · python/cpython Conversation
|
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Ran 2287 tests in 83.131s
OK (skipped=18) All windows tests
Also hit base_events.
Looks good.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
✅ Deploy Preview for python-cpython-preview canceled.
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| self.loop.run_forever() | ||
| except KeyboardInterrupt: | ||
| pass | ||
| self.loop.call_later(0.01, func) |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
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?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
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:
| 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.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Clever solution, go ahead and make it a PR, assign to me or @kumaraditya303 for review.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.