This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mpage
Recipients asvetlov, dino.viehland, itamaro, mpage, yselivanov
Date 2022-03-01.22:13:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1646172818.87.0.620414144341.issue46892@roundup.psfhosted.org>
In-reply-to
Content
Profiling tools that use the call-stack (i.e. all of them) paint an incomplete picture of what’s really going on in async-heavy codebases. They can only show the stack of the currently executing task; they miss the chain of awaitables that are transitively waiting on the current task. To remedy this, we have added support in Cinder to expose the async call-stack. This consists of the call stack for the currently executing task, followed by the chain of awaitables that are transitively reachable from the currently executing task. See below for a clarifying example.

```
async def f1():
  return await f2()

async def f2():
  return await asyncio.ensure_future(f3())

async def f3():
  return await f4()

async def f4():
  await asyncio.sleep(10)
  return 42
```

When retrieved from f4, the two different stacks (top-of-stack last) are:
sync - [f3, f4]
async - [f1, f2, f3, f4] 


We’d like to merge our implementation into CPython so that other heavy users of asyncio can benefit. This will consist of a few parts:

1. A new limited C-API to set and retrieve the “awaiter” of an awaitable object.
2. Additions to PyAsyncMethods to store function pointers for setting and retrieving the awaiter on instances.
3. An API in managed code to retrieve the async call stack as a list of fully qualified names (i.e. <module>:<class>.<function>).
History
Date User Action Args
2022-03-01 22:13:38mpagesetrecipients: + mpage, dino.viehland, asvetlov, yselivanov, itamaro
2022-03-01 22:13:38mpagesetmessageid: <1646172818.87.0.620414144341.issue46892@roundup.psfhosted.org>
2022-03-01 22:13:38mpagelinkissue46892 messages
2022-03-01 22:13:38mpagecreate