Skip to content

implement task objects inside winloop (DRAFT MAY NOT BE FINAL) - #170

Draft
Vizonex wants to merge 1 commit into
mainfrom
tasks
Draft

Vizonex wants to merge 1 commit into
mainfrom
tasks

Conversation

@Vizonex

@Vizonex Vizonex commented Oct 9, 2026

Copy link
Copy Markdown
Owner

What do these changes do?

This change is a draft in response to my inspiration for faster tasks. _asynciomodule.c has 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

asyncio has no C API yet.

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 Future objects now all that is left is to figure out how we implement Task objects. I find it obvious that UVIdle is the correct choice in terms of pausing and resuming a coroutine when a Future or Task is 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 Future objects and Task objects but I stopped it when the module kept on crashing. I'm 100% sure that if someone does implement a Future and Task object 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 multidict 7.0.0 which 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

  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes

This branch has not been deployed

No deployments
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.

1 participant