niedz., 8 paź 2023 o 22:03 Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> 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.
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
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;