[issue46892] Async Call-Stack Reconstruction

[Andrew Svetlov]

Andrew Svetlov  added the comment:

The idea looks interesting.
The devil in the details I guess.
I'm curious what is the memory and performance penalty.
Waiting for the PR as the discussion starting point.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46892] Async Call-Stack Reconstruction

[Guido van Rossum]

Guido van Rossum  added the comment:

I've recently dabbled a bit in some new primitives for asyncio, and based on 
that experience I think this would be very useful.

IIRC Trio does this (presumably at considerable cost) in userland.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46892] Async Call-Stack Reconstruction

[Matt Page]

Matt Page  added the comment:

Sorry for the confusion, I'm working on a PR. I filed the BPO to gauge interest 
in the feature.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46892] Async Call-Stack Reconstruction

[Kumar Aditya]

Change by Kumar Aditya :


--
nosy: +gvanrossum, kumaraditya303

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46892] Async Call-Stack Reconstruction

[Andrew Svetlov]

Andrew Svetlov  added the comment:

> We’d like to merge our implementation into CPython

Could you provide a link first, please?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46892] Async Call-Stack Reconstruction

[Matt Page]

New submission from Matt Page :

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. :.).

--
components: Interpreter Core, asyncio
messages: 414301
nosy: asvetlov, dino.viehland, itamaro, mpage, yselivanov
priority: normal
severity: normal
status: open
title: Async Call-Stack Reconstruction
type: enhancement
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com