Discussion for "C++ Coroutines: Understanding the Compiler Transform"

[Lewis Baker]

Discussion for the post at https://lewissbaker.github.io/2022/08/27/understanding-the-compiler-transform

Also see:
Reddit: https://www.reddit.com/r/cpp/comments/x0bj5z/c_coroutines_understanding_the_compiler_transform/
HackerNews: https://news.ycombinator.com/item?id=32642832

[Barry Revzin]

Can you add permalinks to the section headers? e.g. I can manually link to, let's say, Step 6 by going through the html source but it'd be nice if there were just a link right there. Something like this?.

Also, given the length, a table of contents would be 👌. I'm sure there's some plugin somewhere you can add to do that easily, I just don't know what that is.

[Lewis Baker]

@brevzin Thanks for the tip.

I've added anchor links and a table-of-contents now.

[bilosikia]

very good post!

Step 13: Implementing symmetric-transfer and the noop-coroutine

this is a loop in coroutine_handle resume function，so how can the compiler implement with tail-call?
or just for introduce the principles, there is no loop in real completed generated code?

[Lewis Baker]

this is a loop in coroutine_handle resume function，so how can the compiler implement with tail-call?
or just for introduce the principles, there is no loop in real completed generated code?

There is no guaranteed tail-calls with C++ at the moment.
However, we can emulate a tail-call using a trampolining loop.
A compiler that supports native tail-calls (i.e. can jmp to the next continuation) would not need this loop.

[yangyangyang]

Hello lewissbaker,
Can resume_point be a code address?
How does Awaitable.suspend trigger the resume?

[dreamHuang]

I think there is a conflict with your previous post. In the section "Handling exceptions that propagate out of the coroutine body" of the post Understanding the promise type , you said

My current interpretation of the wording is that if control exits the coroutine-body, either via exception propagating out of co_await promise.initial_suspend(), promise.unhandled_exception() or co_await promise.final_suspend() or by the ... then the coroutine frame is automatically destroyed before execution returns to the caller/resumer.

But in this post, when you put the unhandled_exception in the another try-catch block like following:

try {
  // ...
} catch (...) {
    try {
        state->__promise.unhandled_exception();
    } catch (...) {
        state->__suspend_point = 2;
        state->__resume = nullptr; // mark as final-suspend-point
        throw;
    }
}

This will not cause the coroutine automatically destroyed before return to the caller/resumer. It makes this coroutine in the 'suspended' state and propagate the exception to the caller/resumer.

So which one is the current Coroutine TS wording to the behavior of rethrow exception in unhandled_exception?