Am 02.10.2023 um 18:23 schrieb Klemens Morgenstern via Boost:
What would be a genuine asynchronous coroutine library? asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too.
So if I were to call std::coroutine_handle
::resume() I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.
There is a difference between asymmetric/symmetric coroutine-like control-transfer - see 'P0876: fiber_context - fibers without scheduler'.
Racket does have preemptive fibers which are interrupted asynchronously (much like Golang's goroutines), but coroutines are not fibers. The Lisp community already learned this lesson:
The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well. Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.
There are two kinds of coroutine-like operations - stackful and stackless ops. The C++-20 coroutines are stackless (not realy because some memory has to be allocated to hold the local variables that would usally be stored in the stack frame). The other C++ coroutine-like stackful option has been named 'fiber' by the C++ standards committee (proposal P0876: fiber_context - fibers without scheduler). (C++)-Fibers are asymmetric stackful coroutines implemented by boost.context that do not require a scheduler. boost.fiber is a library using the C++-fibers from boost.context and implements a kind of userland threads (including a scheduler).
https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua
We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
The least we should do is to at least take the time to listen. I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism.
I am pretty sure both had a different vision than what we got, and the dichotomy between fibers & coroutines in this paper arose from their idea of how to separate the concepts.
The paper is deprecated in vafour of P0876. As mentioned above - you have to distinguish between stackless/stackful and symmetric/asymmetric control flow (as described in P0876). Oliver