Skip to content

bpo-45997: Fix asyncio.Semaphore waiters order #30052

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

Closed
wants to merge 1 commit into from
Closed

bpo-45997: Fix asyncio.Semaphore waiters order #30052

wants to merge 1 commit into from

Conversation

hyzyla
Copy link

@hyzyla hyzyla commented Dec 11, 2021

Allow other Semaphore waiters to acquire lock after releasing by current coroutine by skipping one event loop iteration. If everything is OK for Semaphore, I can add the same logic to other asyncio synchronization primitives

https://bugs.python.org/issue45997

@hyzyla hyzyla requested review from 1st1 and asvetlov as code owners December 11, 2021 14:42
@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@hyzyla

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Copy link
Contributor

@asvetlov asvetlov left a comment

Choose a reason for hiding this comment

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

The PR adds unconditional sleep even if the waiting is not needed (the context was switched already).
I think we need an alternative implementation based on future object waiting.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Jan 14, 2022
@taleinat
Copy link
Contributor

taleinat commented Jan 18, 2022

@hyzyla, are you interested in continuing to work on this PR following @asvetlov's comment?

(If so, you will need to to sign the CLA.)

@github-actions github-actions bot removed the stale Stale PR or inactive for long period of time. label Jan 19, 2022
@hyzyla
Copy link
Author

hyzyla commented Jan 19, 2022

I would like to return to PR in few weeks, I have idea where I will create Future, then will put it to loop via call_soon and in the end in acquire method waiting for that Future

@taleinat
Copy link
Contributor

Alright @hyzyla, looking forward to what you'll come up with!

@asvetlov
Copy link
Contributor

#31910 is an alternative fix

@asvetlov
Copy link
Contributor

Thanks for the PR!
Fixed by #31910

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants