Re: [Async] Naming land grab?

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-08 20:02:38

>>
>> I did learn from NodeJS and it was good at the time as it helped to push
>> people for something better. However I also learnt from Boost.Asio,
>> Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside
>> and outside Boost's community. Honestly, NodeJS just got stuck in time. It
>> can't hope to grow more than it already did. If you provide a complete copy
>> of NodeJS inside C++ so NodeJS programmers can come over, what is it that
>> you'll offer for them to come here? They already have NodeJS. You need a
>> differentiating factor.
>
>
> I am convinced by this.

You shouldn't be, because this is not an accurate description of my library.

> If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".

Can you elaborate on what changed your mind exactly?

Libraries like this need a scheduler, boost.fiber has one, too. In the
case of boost.fiber it's much more elaborate, which I don't consider
necessary for async. Hence it just uses a generic scheduler that's
already in boost: boost::asio::any_io_executor. A nice side effect of
that is that users CAN use asio directly with that on a single thread,
but that's not a necessity. They can also plugin their own awaitables,
that have nothing to do with asio.

I got two examples of that

1. co-awaiting a boost.signal2
https://github.com/klemens-morgenstern/async/blob/master/example/signals.cpp
2. co-awaiting an spsc-queue
https://github.com/klemens-morgenstern/async/blob/master/example/spsc.cpp

The latter does use two functions from the asio namespace, that should
probably be pulled into the async namespace. Note that both functions
are related to boost::asio::any_io_executor.

Now, let's say you got five threads producing values and pushing them
out into an spsc-queue. So you got five event sources that now need to
feed a state machine. You can model that with async and since the
co-await will already make sure that all is running on a single
thread, it'll be much easier to write & maintain.
I hope that makes sense.