Boost logo

Boost :

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-02 16:23:00


On Mon, Oct 2, 2023 at 11:33 PM Vinícius dos Santos Oliveira
<vini.ipsmaker_at_[hidden]> wrote:
>
> Em seg., 2 de out. de 2023 às 11:49, Klemens Morgenstern via Boost <boost_at_[hidden]> escreveu:
>>
>> On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost
>> <boost_at_[hidden]> 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<some_async_coro>::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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk