Async Stacks: Making Senders and Coroutines Debuggable
summary
Claims a concrete debugging feature: runtime async stack frames that capture return address when senders are constructed, stored in operation state, and stitched into debugger output via a KOBT/python script so a backtrace follows work back to main. Demo uses Folly origins ported into Unifex/folly proof-of-concept, runs under lldb/GDB on Linux, shows readable call sites, and works end-to-end in demos and Folly deployments, with measurable binary and per-operation memory overhead that teams may opt into.
AI-written summary · about
chapters (21)
- 0:00Async code debugging challenges
- 1:04Async stack traces today
- 3:34Async stack traces for async code
- 4:15History of async stacks
- 5:38Demo app setup
- 6:40Senders and coroutines
- 9:14Async main function breakdown
- 12:08Process file coroutine
- 13:57Live demo traditional traces
- 15:00Debugging limits with tools
- 17:12Async stack trace debugger
- 21:51Async stack frames
- 24:17Debuggers reconstruct traces
- 27:27Sync to async transitions
- 30:00Walking async stack
- 33:11Reconstructing async traces
- 37:26Async stacks in senders
- 40:59Using async stacks in Folly/UNIFX
- 42:02Future plans contributions
- 44:52Platform support challenges
- 46:17Q&A
related talks
29mRust: Embedded, Async, All the Way
31mThe Fullest Stack
59mHow Debuggers Work
01h 06mTrue parallelism, with no concept of threads
07mLightning Talk: Async Function Pointers
31mCoroutine Patterns: Problems and Solutions Using Coroutines in a Modern Codebase
28mDetecting Borrow and Provenance Bugs Across Unsafe Rust [...]
45mAsynchrony and Coroutines