Re: [Async] Review of proposed Boost.Async begins

From: Marcelo Zimbres Silva (mzimbres_at_[hidden])
Date: 2023-08-17 21:01:54

On Tue, 8 Aug 2023 at 07:33, Niall Douglas via Boost
<boost_at_[hidden]> wrote:
>
> Dear Boost,
>
> It is my great pleasure to announce the beginning of the peer review of
> proposed Boost.Async, which is hoped to become the most popular way of
> programming C++ coroutines in future C++. The peer review shall run
> between Tuesday 8th August and Friday 18th August.
>
> <snip>

I recommend ACCEPT Boost.Async in Boost.

More details about my decision can be found in another thread in this
ML. The key points of my decision are

1. It was straightforward to integrate Boost.Redis with Boost.Async.
This is also shown in the report from Ruben Perez in this ML.

2. The docs are well written and read linearly. That is in part
because it does not have to dig into material unrelated to coroutines,
which is important for starters.

3. The library has good defaults: single-threaded contexts, automatic
installation of signal handlers and co_main entry point. This reduces
the cognitive burden for starters, that now won't be tempted into
using multi-threaded contexts and strands. This is likely to result in
better performance by default on anything that is IO bound.

4. I did not measure this myself but the docs claim it has faster e.g.
channels by assuming a single-threaded context. I found this very
surprising. I must say, channels are very important elements in any
asynchronous programming. Any kind of improvements here are welcome.

5. It offers ways (async_ready) of skipping unnecessary suspensions.
I believe this will open the door for countless optimization
opportunities that avoid rescheduling in the Asio event loop, such as
the one I mentioned in the other thread where async_read_utill has
enough bytes in the buffer and does not need to perform any IO.

6. Uses widespread names like select and join that are more easily
recognized by people without Asio background. And offers asynchronous
facilities (with) that aren't available in Asio.

Given all the points above, I am confident Boost.Async can become the
correct place for prototyping and starting new projects that want to
experiment with coroutines. This is going to be important as
high-level Asio libraries pop up in Boost and elsewhere.

One of my main concerns when I saw the start of the review is that
Boost.Async hasn't had much adoption yet and in fact its author has
just finished writing it, at least a version that can be reviewed.
However, it also does not seem correct to me to let this library wait
years before engaging in a review.

I am not making my acceptance conditional, but would strongly
recommend the author to provide more examples about how to write your
own awaitables. This seems to be one of the strongest arguments for
this library, but I don't have experience with them and could neither
appreciate this feature in the docs nor have a feeling about its real
importance.

The last thing I would like to mention is that Klemens, the author of
this proposed library, was the review manager of Boost.Redis, of which
I am the author of. The review manager should take this into
consideration before issuing his final decision since this might be
seen as a conflict of interests. He is free to not take my Review into
consideration if he judges so.

Thanks again to Niall for managing this review and Klemens for submitting it.

Marcelo