Repository navigation
Conversation
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What do these changes do?
This change is a draft in response to my inspiration for faster tasks.
_asynciomodule.chas a few fatal flaws that prevent the full capabilities of a C-API for asyncio python (I wish we had C-API capsule access to tasks and futures) as this gap would then close in around a decade when non-capsule AIs for asyncio would then become obsolete.Andrew Svetlov, a good friend of mine said it perfectly and I quote as far back as 2018
Here we almot 9 years later attempting to close a gap between costly performance bottlenecks and pure python parts the only option is to bring it back to us as we don't know what the other user is using. This could be C-Asyncio or Py-Asyncio (Pure python). Making this ourselves would kill the guessing game entirely, we have already have confirmed this to work with
Futureobjects now all that is left is to figure out how we implementTaskobjects. I find it obvious thatUVIdleis the correct choice in terms of pausing and resuming a coroutine when aFutureorTaskis detected in our path (similar to spotting a deer in the middle of the road with a car and waiting for it to leave).I had some older research that would've used a recasting hack for
Futureobjects andTaskobjects but I stopped it when the module kept on crashing. I'm 100% sure that if someone does implement aFutureandTaskobject outside of asyncio as a third party implementation of these two I would've already brought them over here without much effort or would've been encouraging said user to bring me a capsule similar to the work done on multidict7.0.0which I mark as an accomplishment. But for now those alternate plans are put to bed.Warning
If this meant to be a draft only. There could be hundreds of more rewrites before that perfect balance is found and the workflows are happy. This is a starting point to doing just that. Contributors are welcome here for input as I desperately need it
Are there changes in behavior for the user?
Is it a substantial burden for the maintainers to support this?
Related issue number
#166
Checklist