Re: [Async] Naming land grab?

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-10-10 00:23:11

niedz., 8 paź 2023 o 22:03 Klemens Morgenstern <
klemensdavidmorgenstern_at_[hidden]> napisał(a):

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

As indicated in my original review, I have small experience with
asynchronous computations, so to some extent I have to rely on things like
intuition or trust in other experts' opinions. Vinnie's description "C++
needs coroutine libraries, this is a coroutine library, so let's have it"
correctly addresses my attitude. This is not a criticism of your library,
rather of my attitude. I am not particularly proud of it, but I must admit
this is the case. And this clouded my judgement. Now that other peoples'
critical opinions cooled my enthusiasm, I realise that the concerns I
raised as conditions for acceptance are more serious.

I believe a Boost.Library should have a solid design that is reflected in
its documentation. That is, not only should it be solid, but you also
should demonstrate it (in the docs). I am missing this from reading the
docs. The choice of names (promise, task), the concepts that I cannot grasp
after hours of struggling (spawning, interrupting, detaching), the parts of
the design of generator that you admit may make no sense (eager value
consuming generator), this all is a signal for me that the library might
not have a solid design. I may be wrong about this, of course, but I would
rather err on the safe side, and hence my decision. I understand the
recommendation to reject as saying, "do not accept the library in its
current shape, give the author the time, guidance and opportunity to come
back with the improved design." I now think that unclear design is too
serious for conditional acceptance.

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 understand that an async library needs a scheduler. The docs say, "async
uses an asio::io_context as its default event loop" which implies that it
can be used with other event loops. You give two examples

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

I must admit they are too complicated for me. But let me ask a question
instead. If I am using my own event loop in my project, how do I adapt it,
so that it is usable with Boost.Async? I do not expect an explanation in
this distribution list. I would expect an answer in the docs.

I am not that much concerned about the user base, or novelty, or the number
of reviews. But it is this lack of certainty that the design is solid and
stable. My apologies for not indicating it earlier. I guess I feel
uncomfortable recommending a rejection after the author spent so much time
developing the library, fine tuning it and answering all my questions.

I hope that this reply makes sense.

Regards,
&rzej;