Skip to content
New issue

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

gh-79033: Try to fix asyncio.Server.wait_closed() again #111336

Merged
merged 2 commits into from
Oct 28, 2023

Conversation

gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented Oct 25, 2023

I identified the condition that wait_closed() is intended to wait for: the server is closed and there are no more active connections.

When this condition first becomes true, _wakeup() is called (either from close() or from _detach()) and it sets _waiters to None. So we just check for self._waiters is None; if it's not None, we know we have to wait, and do so.

A problem was that the new test introduced in 3.12 explicitly tested that wait_closed() returns immediately when the server is not closed but there are currently no active connections. This was a mistake (probably a misunderstanding of the intended semantics). I've fixed the test, and added a separate test that checks exactly for this scenario.

I also fixed an oddity where in _wakeup() the result of the waiter was set to the waiter itself. This result is not used anywhere and I changed this to None, to avoid a GC cycle.


📚 Documentation preview 📚: https://cpython-previews--111336.org.readthedocs.build/

I identified the condition that `wait_closed()` is intended
to wait for: the server is closed *and* there are no more
active connections.

When this condition first becomes true, `_wakeup()` is called
(either from `close()` or from `_detach()`) and it sets `_waiters`
to `None`. So we just check for `self._waiters is None`; if it's
not `None`, we know we have to wait, and do so.

A problem was that the new test introduced in 3.12 explicitly
tested that `wait_closed()` returns immediately when the server
is *not* closed but there are currently no active connections.
This was a mistake (probably a misunderstanding of the intended
semantics). I've fixed the test, and added a separate test that
checks exactly for this scenario.

I also fixed an oddity where in `_wakeup()` the result of the
waiter was set to the waiter itself. This result is not used
anywhere and I changed this to `None`, to avoid a GC cycle.
@gvanrossum
Copy link
Member Author

Maybe @graingert has some time to review? (I'll trade you -- I'm reviewing #110728 right now.)

Copy link
Contributor

@willingc willingc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @gvanrossum for the additional comments and clarification. I'm making one small docstring clarification and then will merge.

Lib/asyncio/base_events.py Show resolved Hide resolved
@willingc willingc enabled auto-merge (squash) October 28, 2023 17:36
Copy link
Member Author

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@willingc willingc merged commit 2655369 into python:main Oct 28, 2023
24 checks passed
@miss-islington-app
Copy link

Thanks @gvanrossum for the PR, and @willingc for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

@bedevere-app
Copy link

bedevere-app bot commented Oct 28, 2023

GH-111424 is a backport of this pull request to the 3.12 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.12 bug and security fixes label Oct 28, 2023
@gvanrossum gvanrossum deleted the fix-wait-closed branch November 1, 2023 15:48
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.

3 participants