René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add eager task creation API to asyncio","articleBody":"# Feature or enhancement\r\n\r\nWe propose adding “eager” coroutine execution support to `asyncio.TaskGroup` via a new method `enqueue()` [1].\r\n\r\n`TaskGroup.enqueue()` would have the same signature as `TaskGroup.create_task()` but eagerly perform the first step of the passed `coroutine`’s execution immediately. If the `coroutine` completes without yielding, the result of `enqueue()` would be an object which behaves like a completed `asyncio.Task`. Otherwise, `enqueue()` behaves the same as `TaskGroup.create_task()`, returning a pending `asyncio.Task`.\r\n\r\nThe reason for a new method, rather than changing the implementation of `TaskGroup.create_task()` is this new method introduces a small semantic difference. For example in:\r\n\r\n```\r\nasync def coro(): ...\r\n\r\nasync with TaskGroup() as tg:\r\n  tg.enqueue(coro())\r\n  raise Exception\r\n```\r\n\r\nThe exception will cancel everthing scheduled in `tg`, but if some or all of `coro()` completes eagerly any side-effects of this will be observable in further execution. If `tg.create_task()` is used instead no part of `coro()` will be executed.\r\n\r\n\r\n# Pitch\r\n\r\nAt Instagram we’ve observed ~70% of coroutine instances passed to `asyncio.gather()` can run fully synchronously i.e. without performing any I/O which would suspend execution. This typically happens when there is a local cache which can elide actual I/O. We exploit this in [Cinder](https://github.com/facebookincubator/cinder) with a modified `asyncio.gather()` that eagerly executes `coroutine` args and skips scheduling a `asyncio.Task` object to an event loop if no yield occurs. Overall this optimization saved ~4% CPU on our Django webservers. \r\n\r\nIn a prototype implementation of this proposed feature [2] the overhead when scheduling `TaskGroup`s with all fully-synchronous coroutines was decreased by ~8x. When scheduling a mixture of synchronous and asynchronous `coroutine`s, performance is improved by ~1.4x, and when no `coroutine`s can complete synchronously there is still a small improvement.\r\n\r\nWe anticipate code relying on any semantics which change between `TaskGroup.create_task()` and `TaskGroup.enqueue()` will be rare.  So, as the TaskGroup interface is new in 3.11, we hope `enqueue()` and its performance benefits can be promoted as the preferred method for scheduling coroutines in 3.12+.\r\n\r\n# Previous discussion\r\n\r\nThis new API was discussed informally at PyCon 2022, with at least some of this being between @gvanrossum, @DinoV, @markshannon, and /or @jbower-fb.\r\n\r\n[1] The name \"`enqueue`\" came out of a discussion between @gvanrossum and @DinoV.\r\n\r\n[2] [Prototype implementation](https://github.com/python/cpython/compare/3.11...DinoV:eagertaskgroup) (some features missing, e.g. specifying Context), and [benchmark](https://gist.github.com/jbower-fb/b52d40bec31d578cadc643b5bad8a485).\r\n\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-101613\n* gh-102853\n* gh-104188\n* gh-104189\n* gh-104216\n* gh-104255\n* gh-104256\n* gh-104298\n* gh-104304\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/jbower-fb","@type":"Person","name":"jbower-fb"},"datePublished":"2022-09-30T22:55:46.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":38},"url":"https://github.com/97696/cpython/issues/97696"}