Re: [boost] [Async] Naming land grab?

On Mon, Oct 2, 2023 at 11:33 PM Vinícius dos Santos Oliveira wrote:

Em seg., 2 de out. de 2023 às 11:49, Klemens Morgenstern via Boost escreveu:

...

On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost wrote:

...

I'm not going to submit a review but I do think the name is almost a misnomer.

The library is essentially just an Asio wrapper and isn't a genuine coroutine library.

What would be a genuine asynchronous coroutine library?

Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously).

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.

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.

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. .

Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines.

I am not familiar with ruby, but I reckon you'd consider goroutines to be fibers? The promise issue is why my library makes a distinction between an awaitable and a coroutine. It's not just syntactic sugar for promises, although I wonder why that would be a bad thing? What's wrong with using coroutines to get out of callback-hell? And I do agree with you, that coroutines are a wider topic, which is why my library is called async. I don't think it's the one true coroutine library, nor is it meant to be. Rather the idea is to allow it to interact with other coroutine libraries. For example, if you were to build a coroutine based stream parser you should be able to make it work asynchronously with an io stream based on boost.async.

So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated.

The coroutines you get with the async keyword in python or javascript, which means coroutines that run on a scheduler. Both languages have coroutines that are not async, too.