On Tue, 8 Aug 2023 at 07:33, Niall Douglas via Boost
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