Implicit coro argument to yield etc

[malthe]

Currently, coro_yield and friends take the currently running coro as an argument.

It would simplify the API and strengthen the coro abstraction if user code did not have to know more than e.g. coro_yield(CONN_ABORT) – or even just lwan_abort().

This can be done using thread-local storage:

static __thread int current;

The user-level coro_* functions can then look up this value. This is pretty fast because most processors provides native support it.

[lpereira]

This has been considered in the past, but because the template code uses coroutines as well, there's the need to support nested coroutines to expand sequences.

I still haven't found a good way of solving this problem without making weird changes to the API (such as having a 'main coroutine' where TLS would be used, and subcoroutines, where one would need to pass the coroutine as a parameter).

[malthe]

That makes sense. What's mostly weird is that a coroutine needs a reference to what's essentially itself. I tried to implement a "proof of concept" and it seems to work except there are some details for the ucontext fallback.

[lpereira]

Closing this: it would indeed be convenient for coroutines to have a reference to themselves, but this would complicate a lot becuase of the corner cases with nested coroutines.