August 2023 - Boost - lists.boost.org

[Async] Review ends tomorrow
by Niall Douglas 17 Aug '23

17 Aug '23

Dear Boost, The peer review of Boost.Async ends tomorrow. Currently no reviews have been received, there has been almost no discussion, and it appears nobody has been testing Klemens' library. Unless there is a major change by tomorrow, I suspect we'll have to try this again next month when more people return from summer holidays. Niall

4 3

Review of proposed Boost.Async
by Ruben Perez 15 Aug '23

15 Aug '23

Hi all, Thanks Klemens for submitting this library. I've taken a different approach for the review this time. I've tried to build something useful with it. I was already writing a web chat application with a C++ backend. It was using Boost.Context coroutines (the ones you get with boost::asio::spawn). I have rewritten the server to use Boost.Async coroutines. This email is not a review (I'll write it later), but just a summary of my experience using the library, in case anyone finds it useful. You can see the full source code here: https://github.com/anarthal/servertech-chat/tree/async-rewrite/server The application =============== It is a super-simplistic chatting application, where users can send messages that get broadcast to other users in the same chat room. The application uses a HTTP webserver to serve static files, websockets for message broadcasting and Redis for message persistence. It uses Boost.Asio, Boost.Beast, Boost.Redis and now Boost.Async (together with other foundational Boost libraries). My experience ============= I've been able to rewrite it and make it work. I've had some problems (which I described below) but have been able to solve them. Control flow was mostly identical to stackful coroutines, except in some key places I describe below. I've used the use_op token extensively to interoperate with Beast and Redis. As proposed, it causes problems with Beast's websockets, as it's moving the websocket's internal implementation. As a result, after the first initiation that uses use_op, the websocket is rendered unusable. I could overcome it by slightly modifying use_op's implementation. This is tracked by https://github.com/klemens-morgenstern/async/issues/68. It's still under discussion whether this is a bug in Async or in Beast. use_op uses a per-operation, stack-based memory pool of 2KB internally. It creates a completion handler with an associated allocator that will consume this stack-based memory before calling operator new. The pool gets destroyed once the co_await expression finishes execution. I had a problem with Boost.Redis, where redis::connection::async_exec was calling complete() without releasing the memory allocated in the operation, which led to crashes. I think it's a problem in Boost.Redis, not in Async. Tracked by https://github.com/boostorg/redis/issues/140. By default, use_op converts error codes to exceptions. This is consistent with Asio's use_awaitable, but it's a setting I personally don't like using. However, it's easy to adapt it by using asio::as_tuple(async::use_op) as completion token. This should probably be mentioned in docs. I'm using async::with to clean-up Redis connections on application exit. I think it's a very useful feature, and one that Asio doesn't offer. It would be a nice addition to be able to return values from the with call though, to make code less verbose. Tracked by https://github.com/klemens-morgenstern/async/issues/69. As any Beast-based HTTP server, my code has a TCP acceptor that listens for connections and launches HTTP sessions. At first, I was running these sessions as detached promises (by using async::promise::operator+). This caused a deadlock on finalization. async::co_main does not cancel detached promises, but does wait for them to finish after receiving a SIGINT. I solved this by placing my promises in an async::wait_group instead of detaching them. However, I think this behavior is non-obvious and can cause problems for people less experienced with Asio. I've raised https://github.com/klemens-morgenstern/async/issues/72 to track this. I'm currently using detached promises to broadcast messages over websocket sessions. Compared to asio::spawn, spawning detached tasks in Boost.Async is significantly easier. As you may know, when using Beast's websockets, you need to make sure that the application doesn't perform two concurrent async reads or writes on the same websocket at the same time. In this chat server, two concurrent writes can happen if two messages need to be broadcast at the same time. Thus, I was using a hand-rolled async_mutex, based on Asio channels, to guarantee mutual exclusion (unfortunately, there is no asio::mutex). I tried re-writing my async_mutex using async::channel, but I couldn't, because my implementation relied on asio::channel::try_send, which Async does not offer. It would be great if this library could offer async locking primitives, like mutex, condition_variable or event, like Python's asyncio does. I don't think this is a requirement for inclusion, though. I then decided to remove the mutex and base my strategy on channels. Websocket reads and writes are now managed by a single coroutine. If any other session needs to write through a different session's websocket, it writes a message through a channel. The coroutine running the websocket session reads from the websocket and the channel in parallel, using async::select. My first, naive implementation used async::select(websocket.async_read(..., use_op), channel.read()). This does not work as intended because, if the channel read completes first, select will cancel the websocket read, which will cause the websocket connection to close. This can be overcome easily with generators, as they implement the wait_interrupt mechanism. If the channel read completes first, the generator can be resumed later, without losing information. Although there exists an asio::experimental::parallel_group with similar functionality, I don't think this channel-based strategy could be achieved using plain Asio, since the non-destructive capabilities of the generator are vital. parallel_group is also almost undocumented, which makes it difficult to use. My only concern with channels as they are is that channel.read() will throw an exception on cancellation. This means that async::select(websocket_generator, channel.read()) will throw-and-catch an exception internally every time a message arrives on the websocket. I believe that exceptions should be exceptional, and it's not the case here. It makes debugging harder, and may have a performance impact (which I haven't measured). https://github.com/klemens-morgenstern/async/issues/76 tracks this. I've been able to successfully build this project using clang-17 under Linux. I had problems building wait_group under gcc-12 (https://github.com/klemens-morgenstern/async/issues/73) Some other minor issues I found: * https://github.com/klemens-morgenstern/async/issues/75 * https://github.com/klemens-morgenstern/async/issues/66 * https://github.com/klemens-morgenstern/async/issues/71 Some of these issues have already been fixed in the develop branch by Klemens. If you're trying the library, I'd advise you to use this branch. Questions ========= Q1. Is it possible to somehow address the deadlock problem? Q2. Is it possible to get non-throwing overloads of the channel functions? Q3. The docs mention that MSVC compilers have broken coroutine implementations. What compilers/OS does this library target/has been tested with? Thanks Klemens for making the async world less painful. Regards, Ruben.

1 0

Review of proposed Boost.Async
by Marcelo Zimbres Silva 14 Aug '23

14 Aug '23

Hi, this is my review of the proposed Boost.Async. Before I issue my final decision (ACCEPT/REJECT) I would like to ask the author some questions. First of all, I have plenty of reasons to want a library such as Boost.Async into Boost. Some of them are * A common concern I hear from my peers is that Asio is too difficult to get started with. One of the reasons for that is that its Universal Asynchronous Model built around the completion token is too generic for most use cases and in some cases encourages just bad practice like the use_future token. A library like Boost.Async that adds a thin coroutine-only layer over Asio and its corresponding facilities like select, gather etc. will lower the entrance barrier in the Asio asynchronous world. * Docs: Even Asio experts agree that Asio documentation is not easily digestible (async_initiate I am looking at you) and I think it will be difficult for its author alone to address users' complaints given how low-level and generic Asio is. Also, regular users should not be bothered with many of the details. Boost.Async documentation is linear and to the point. It uses names that are more easily recognized by people coming from other languages, like select and with. * NodeJs and Go Tokio, etc. have shown us that successful networking libraries will flourish once a decent asynchronous environment is available. We have more than that, Asio is robust and battle tested, but I am afraid it might not be the correct ground on which high-level abstractions should be prototyped and evolved, not every library needs Duff's device to perform some milliseconds better. As I mentioned above, it is perhaps too generic and low-level and a layer over it might be necessary. Boost.Async looks like the correct step in that direction. We will be one step closer to writing code that is as simple as python, NodeJs, etc. but that runs at C++ speed. * It will help us gather more field experience with C++20 coroutines in domains where C++ is extensively used, like high-performance network servers. * Boost.Async has good defaults, for example a single threaded context. Too many people play around with multi-thread io_context and strands not knowing it might actually have a negative impact on performance. This is also likely to play well with other network Boost networking libraries like Boost.Beast, Boost.MySql and Boost.Redis. Also, the automatic installation of signal handling is a good thing. Q1: Default completion token for other Boost libraries ================================================================ I guess it will be a very common thing for all apps using Boost.Async to have to change the default completion token to use_op or use_task. Like you do in the examples > using tcp_acceptor = async::use_op_t::as_default_on_t<tcp::acceptor>; > using tcp_socket = async::use_op_t::as_default_on_t<tcp::socket>; Could this be provided automatically, at least for other Boost libraries? I know this would be a lot of work, but it would make user code less verbose and users would not have to face the token concept at first. Q2: Lazy vs Eager ================================================================ > It’s an eager coroutine and recommended as the default; Great, we can experiment with eagerness and laziness. But why is an eager coroutine recommended as default? Q3: async_ready looks great ================================================================ > We can however implement our own ops, that can also utilize the > async_ready optimization. To leverage this coroutine feature, async > provides an easy way to create a skipable operation: I think I have a use case for this feature: My first implementation of the RESP3 parser for Boost.Redis was based on Asio's async_read_until, which like every Asio async function, calls completion as if by post. The cost of this design is however high in situations where the next \r\n delimiter is already in the buffer when async_read_until is called again. The resulting rescheduling with post is actually unnecessary and greatly impacts performance, being able to skip the post has performance benefits. But what does *an easy way to create a skipable operation* actually mean? Does it - avoid a suspension point? - avoid a post? - act like a regular function call? Q4: Synchronization primitives ================================================================ Will this library ever add synchronization primitives like async mutexes, condition variables, barriers etc. Or are they supposed to be used from an external library like proposed Boost.Sem. Q5: Boost.Async vs Boost.Asio ================================================================ I use C++20 coroutines whenever I can but know very little about their implementation. They just seem to work in Asio and look very flexible with use_awaitable, deferred, use_promise and use_coro. What advantage will Boost.Async bring over using plain Asio in regards to coroutine? NOTE1 ================================================================ > Please state your experience with C++ coroutines and ASIO in your > review, and how many hours you spent on the review. I have spent a bit more than a day reading the docs, writing the review and integrating Boost.Redis. My experience with C++20 coroutines is limited to using them with Asio. I would also like to thank Klemens for submitting Boost.Async and Niall for offering to be its review manager. Marcelo

3 4

Re: [boost] [Async] Review of proposed Boost.Async begins
by Niall Douglas 14 Aug '23

14 Aug '23

On 08/08/2023 06:33, Niall Douglas wrote: > 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. A reminder that five days remains for this review. To date, I have received zero reviews. Niall

3 2

The master branch is now open for all changes
by Marshall Clow 11 Aug '23

11 Aug '23

Next deadline: October 25th - Boost 1.84.0 closed for new libraries and breaking changes` As always, the calendar is at: https://www.boost.org/development/ — Marshall

1 0

[release] Boost 1.83.0
by Marshall Clow 11 Aug '23

11 Aug '23

Release 1.83.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release one new library: * Boost.Compat: A repository of C++11 implementations of standard components added in later C++ standards, from Peter Dimov and contributors. The release also contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.83.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes

1 0

[release] Boost 1.83.0 Release Candidate 2 is available
by Marshall Clow 10 Aug '23

10 Aug '23

The second release candidates for the 1.83.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source/> The SHA256 checksums are as follows: c86bd9d9eef795b4b0d3802279419fde5221922805b073b9bd822edecb1ca28e boost_1_83_0_rc2.zip 6478edfe2f3305127cffe8caf73ea0176c53769f4bf1585be237eb30798c3b8e boost_1_83_0_rc2.tar.bz2 c0685b68dd44cc46574cce86c4e17c0f611b15e195be9848dfd0769a0a207628 boost_1_83_0_rc2.tar.gz 22ee9dcf3f1fb58f585772f70c69113a4077b92adeac58b643b3543b78633a16 boost_1_83_0_rc2.7z The only change between RC1 and RC2 is the addition of some missing "#include"s in Boost.Unordered As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

5 5

[release] Boost 1.83.0 Release Candidate 1 is available
by Marshall Clow 08 Aug '23

08 Aug '23

The first release candidates for the 1.83.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source/> The SHA256 checksums are as follows: 9e99f679ea059a25a11bbcb46141868b71c1b33cf89fac916fa392cff20d1577 boost_1_83_0_rc1.7z 4c1cfd15a92ce003a5c2f4bd11311225e7fe42c6686bffabc64e41534167395d boost_1_83_0_rc1.tar.bz2 0571eb39fc0dd92cc8d1d01d3197c58bb28043392e1038df57090676fd6574fa boost_1_83_0_rc1.zip 2d6cf669fb45a2c1e2f92f90c9d444b19a4af25420fbf54747366f637a22a3f7 boost_1_83_0_rc1.tar.gz As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

8 13

Status of the 1.83.0 release
by Marshall Clow 08 Aug '23

08 Aug '23

On Thursday, we created 1.83.0 RC1. There have been two problems reported against it. * A couple of missing “include” statements in Unordered * A regression against 1.82.0 (code that used to compile no longer does) in Stl_interfaces. https://github.com/boostorg/stl_interfaces/issues/62 Zach has opined to me that this failure in stl_interfaces is deliberate; so we will not be addressing that. We will be producing an RC2 later today/early tomorrow with the fix for Unordered. This means that the release will probably NOT happen on Wednesday, 9-Aug. Hopefully Thursday. — The release managers.

1 0

[release] Master Branch is closed for ALL changes
by Marshall Clow 03 Aug '23

03 Aug '23

Please do not commit anything to the master branch. Other branches are always fine. The 1.82.0 release is scheduled for next Wednesday, 10-Aug. — Marshall

1 0