I’ve heard coroutines in C++20 were dead on arrival (especially on embedded) because it may liberally do heap allocations to store locals and there’s no way to control this. (Typical library implementations I’ve seen for lightweight coroutines/fibers seem to set the stack size for each coroutine as fixed…)
You can provide a custom implementation for "operator new" for the coroutine, so you could instead use some sort of preallocated buffer to store the coroutine frame (or some other custom memory management scheme), but yeah the design assumes that sometimes there will be a need to stash the state of the coroutine somewhere.
Oh what a shame! I just replied to the parent comment (before seeing your reply) about how incredible async/await “coroutines” were with embedded rust requiring actually zero runtime cost (no alloc, no runtime, no dynamic scheduler).
