June 2026 - Boost - lists.boost.org

Boost Review for Capy and Corosio - June 23 to July 7th
by Jeff Garland 09 Jul '26

09 Jul '26

Dear Boost Community: The Boost Formal Review of the *Corosio* and *Capy* libraries will begin on *June 23, 2026* and will conclude on *July 7, 2026*. I'm Jeff Garland and I'll be the review manager. I'd like to thank Vinnie for inviting me to maintain the continuity from Boost.Asio and I'll apologize now for the late notice. Since this is a two library review the period is somewhat extended from normal. In fact my personal pre-review indicates we will likely need an extension due to the size of the libraries -- I'll work with the review wizards on that. Capy Capy is a coroutine foundation library providing task types, execution contexts, executors, asynchronous synchronization primitives, buffer abstractions, and coroutine composition facilities. It serves as the execution and asynchronous programming substrate upon which Corosio is built. Repository: - Capy GitHub Repository <https://github.com/cppalliance/capy?utm_source=chatgpt.com> - docs <https://develop.capy.cpp.al/capy/index.html> Corosio Corosio is a coroutine-native asynchronous I/O library for C++20. It provides networking and I/O facilities designed specifically for coroutines, with awaitable operations, executor affinity, cancellation support, and cross-platform implementations based on IOCP, epoll, and kqueue. Repository: - Corosio GitHub Repository <https://github.com/cppalliance/corosio?utm_source=chatgpt.com> - docs <https://develop.corosio.cpp.al/corosio/index.html> Review Questions Potential reviewers are encouraged to consider the following questions: 1. What is your evaluation of the usefulness of the libraries? 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. Have you used either or both libraries? What was your experience? 6. Are the libraries ready for inclusion in Boost? 7. If not, what changes would you recommend before acceptance? 8. Do the libraries fit well within the existing Boost ecosystem? 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed? How to Participate Please post your review to the Boost Developers mailing list. Reviews from both experienced Boost contributors and first-time reviewers are encouraged. Reports based on real-world usage, experimentation, code inspection, and documentation review are all valuable contributions. At the conclusion of the review period, the review manager will consider all feedback and determine whether the libraries should be accepted into Boost. We look forward to your participation in this review.

19 72

[icl] Request to merge PR#54
by Joaquin M López Muñoz 08 Jul '26

08 Jul '26

Hi, In its version 22, libc++ introduced changes to their implementation of non-heterogeneous lookup for associative containers that break some assumptions Boost.ICL relies on: https://github.com/llvm/llvm-project/issues/183189 Turns out lookup for associative containers has been poorly specified since forever. I submitted an issue to the WG21 committee positing that a resolution should be adopted that (among other things) would make Boost.ICL assumptions correct: https://cplusplus.github.io/LWG/issue4572 In the latest meeting in Brno, however, the committee decided against that resolution with the result that, pending an upcoming reformulation of the affected part of the standard, Boost.ICL will be officially relying on undefined behavior. I've written a PR to circumvent this problem: https://github.com/boostorg/icl/pull/54 that relies on heterogeneous lookup (well defined and compatible with the asumptions made by Boost.ICL). I contacted the library maintainer some weeks ago but received no answer, so I'm asking here for this PR to be merged before Boost 1.92, since without it, Boost.ICL is currently broken for libc++ v22. FWIW, some users of Boost.ICL are already applying this fix to their local deployments of Boost: https://github.com/azahar-emu/ext-boost/commit/6a85c3100499e886e11c87a5c210… Another contributor has posted a different PR with the same goal: https://github.com/boostorg/icl/pull/57 My analisys is that this PR is not as comprehensive as PR#54 (it fails to cover intervals of type right_open_interval and related), plus its performance is probably slightly inferior, so I still recommend that PR#54 be used instead. Thank you, Joaquín M López Muñoz

3 4

[Capy/Corosio review] Benchmark results
by Marcelo Zimbres Silva 04 Jul '26

04 Jul '26

Hi, some months ago I started implementing new benchmarks for Boost.Redis to compare it to the current state of other popular clients. While underway with it Boost.Redis gained Corosio support, something that has been announced by Ruben Perez in this mailing list recently. In this email I would like tol share the results I obtained for appreciation by the Capy/Corosio review audience. The code is public and available at https://github.com/mzimbres/redis-cli-comp. The new benchmarks simulate a scenario where Redis is mostly used, namely, internet facing servers (usually HTTP) that serve connections concurrently while receiving server pushes e.g. pubsub events. It consists of 1. starting multiple independent sessions that issue commands in a loop. 2. subscribing to a channel to receive pubsub events. ## Runtime Performance The metric used to assess the runtime performance was the wall-clock multiplied by %CPU consumption used by the client. This metric takes into account that clients might use a different number of threads. The following result were obtained (lower is better) Client Time x %CPU (nomalized) ------------------------------------------------------------------- boost_redis_corosio 1.00 boost_redis_asio_cb 1.35 boost_redis_asio_co 1.73 redis_rs (Rust) 4.62 go_redis (Go) 22.33 The thread and file-descriptor usage by each client was Client threads fd-nr -------------------------------------------------- boost-redis-corosio 3 7 boost-redis-asio-co 2 7 boost-redis-asio-cb 2 7 redis-rs 1 10 go-redis 24 1006 ## Application build time This is the time taken to build the benchmark program excluding the time taken to build the client library Library Time (s) --------------------------------------- boost-redis-corosio 1.68 boost-redis-asio-co 3.60 boost-redis-asio-cb 8.62 redis-rs 3.10 go-redis 0.28 ## Client build time Here we see the time taken to build only the client Library Time (s) ------------------------------------------- boost-redis-lib-corosio 5.3 boost-redis-lib-asio 21.7 redis-rs 9.6 Note: I haven't found a way to measure this for go clients. ## Total build time The times below include the build time of all dependencies (which have been previously downloaded) Client Time (s) --------------------------------------- boost-redis-corosio 33.6 boost-redis-asio-co 35.5 boost-redis-asio-cb 40.5 redis-rs 42.6 go-redis 9.0 ## Executable size That is the size of release builds of each benchmark program. Executable Size -------------------------------------- boost_redis_corosio 1.5M boost_redis_asio_cb 1.9M boost_redis_asio_co 1.3M redis_rs 2.0M go_redis 8.2M ## Summary It is not the point of this report to analyse the results in detail or emit any verdict, Corosio however has come out with really impressive results IMO. Marcelo

6 21

What an error message must do
by Udo Steinbach 03 Jul '26

03 Jul '26

I’d like to raise a practical issue with the current direction of error-handling support. In my experience, existing models still leave too much uncertainty for both human and programmatic consumers of error information. I’m interested in whether a more general boost::exception-style mechanism could preserve richer diagnostic context without forcing users into narrow error codes or lossy secondary return values. A general-purpose error-handling facility should preserve as much diagnostic information as possible, keep that information available for both human and programmatic consumers, and remain highly reliable itself. An error message must enable the user of the program to identify the cause and investigate or fix it without further assistance, without experiments, without guesswork, and without help from third parties. It must also be usable programmatically. To do that, it must identify four points: * The action triggered by the user or by an automated process in whose context the error occurred, including the consequences of incomplete execution, for example: “Not all mails could be retrieved; the missing ones are still on the server.” This is not the task of error handling itself, but of the top level, the user of the error-handling facility. * The cause, that is, the detected state, for example a full disk. * The object, such as a file path, device name, or similar, on which * the named operation failed: reading, writing, opening a window. Unless there are compelling reasons to the contrary, these points must have top priority; neglecting them is inexcusable. It is not enough to simply produce text at the end; rather, the text must be part of the diagnosis that begins with the message. Ideally, it implicitly suggests a necessary or at least obvious course of action. For logging purposes, it must also allow later diagnosis. That is the task of the caller or an external instance, but the error must include the point of state recognition and the triggering operation. Taken together, these requirements mean that many participating levels and instances must collect information, and each must also have the opportunity to make use of it and act accordingly. At the same time, no error-handling mechanism itself may become a source of errors; it must handle any runtime errors occurring within itself definitively. Errors that occur during error handling do not only lead to technical difficulties, but “errors during errors” can also conceal or distort the original error, or lead to unmanageable or otherwise unrecoverable follow-up errors. In my view, there is no alternative to making error handling itself free of errors. Existing solutions often do not take this requirement into account. The widely unsatisfactory state of error messages shows that more is needed than yet another proposal. A good solution in boost could show what error messages should look like in the first place. Udo -- Mit Radwegen lernte ich den Menschen kennen. http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E

4 8

[capy] error codes
by Andrzej Krzemienski 02 Jul '26

02 Jul '26

Hi Everyone, Stream operations often return error codes (they still throw exceptions) and I am trying to wrap my head around how they can be processed. Functions pull_from and push_to special-case on cond::eof. So do a number of examples in the docs. Why only this one? I have been told that cond::stream_truncated means "end of file, transmission ended before the handshake, may be a truncation attack, may be a safe end, judge yourself." How can users make this call when some Capy functions already discard it? BTW, looking at the implementation of pull_from and push_to, when an error is reported, there is no way to figure out from which stream it originated. Looking at the implementation in normalize_openssl_shutdown_read_error in Corosio, it looks like when we decide to stop a task reading an SSL stream we will not get cond::canceled, but instead we may get cond::stream_truncated. This is the only place where -- against the protocol -- we do not get the feedback that the operation was canceled as requested. BTW, cond::canceled detects two things: a successfully processed cancellation request (error::canceled) and other events, possibly caused by the state of the socket at the other end.(std::errc::operation_canceled). It is not a practical condition. Regards, &rzej;

2 3

[Capy] Review Note
by Vinnie Falco 01 Jul '26

01 Jul '26

This review has surfaced a documentation problem that I want to address directly. Several reviewers have arrived at different (incompatible) conclusions about what Capy is, because we never stated it plainly. Let me try now. *What Capy is* Capy is a proposed standard protocol for coroutine environment propagation, plus a reference implementation of that protocol. The protocol (IoAwaitable) ensures that three things flow correctly through co_await chains: executor, stop token, and allocator. The concrete library - thread pool, task types, byte streams, synchronization primitives - exists to prove the protocol works in practice. *The invariant* Capy enforces one rule: A coroutine always resumes on the executor it was launched with. This isn't a restriction for its own sake. Consider: capy::task<void> handle_client(connection& conn) { auto req = co_await conn.read(); auto resp = process(req); co_await conn.write(resp); conn.stats.requests++; } Launch this on a strand. Every resumption after co_await happens on that strand. conn.stats.requests++ is data-race-free without a mutex. Correct by construction. Without the invariant, after co_await conn.read() you might resume on an io_uring completion thread, a random pool thread, anywhere the I/O subsystem completed. Now you need either a mutex around every access to shared state, or a manual co_await resume_on(my_strand) after every co_await. The first defeats strands. The second is verbose, repetitive, and if you forget one, you have a silent data race. The invariant makes the correct thing automatic and the incorrect thing a compile error. *Why IoAwaitable, not plain awaitables* A plain awaitable can resume a coroutine on any thread by calling coroutine_handle::resume() directly. That breaks the invariant. The compile error when you co_await a plain awaitable from a Capy coroutine is the type system preventing this. This isn't about locking you in. It's about making environment propagation explicit. An IoAwaitable receives the io_env (executor + stop token + allocator) and promises to dispatch the resumption through the executor. That promise is what enables the safety guarantee. *The interop problem* Without a shared protocol, N coroutine libraries need N*(N-1) adapters. With a standard protocol for environment propagation, one bridge covers everyone. IoAwaitable is our proposal for that protocol. Capy is the testbed. The papers (P4172, P4092, P4093) are the standardization path. *What Capy is not* Capy is not a general-purpose "do everything" coroutine framework competing with TooManyCooks feature-for-feature. It is not an implementation detail of Corosio. It is the execution model and byte-stream layer - usable standalone for business logic that operates on streams without platform I/O (HTTP parsing, protocol state machines, serialization), and usable as the foundation for Corosio's networking layer. CERN's traccc project uses Capy without Corosio for GPU reconstruction pipelines. The Boost.HTTP parser is implemented entirely on Capy's byte streams. These are the intended use cases for Capy alone. *What went wrong in this review* The documentation never stated any of the above. It explained the API without explaining the design's purpose. Rainer encountered a type-safety check, found no documentation for the escape hatch, and concluded the escape hatch didn't exist. The frustration was understandable. The documentation failed him. We are fixing this. Bikeshed ideas: Cowaitable, Exwaitable Thanks

7 30

Capy review
by Ruben Perez 30 Jun '26

30 Jun '26

Hi all, This is my formal review of the proposed Capy and Corosio libraries. I am currently affiliated with the C++ Alliance. 1. What is your evaluation of the usefulness of the libraries? Immense. C++20 coroutines offer a robust alternative to other async completion models, without their pitfalls and hacks (looking at you, callback hell!). Coroutines for I/O also feature a unique set of problems (are you _really_ sure that _all_ your handlers are going through the appropriate asio::strand?). Having a Boost-quality set of libraries that solve these problems is really useful. 2. What is your evaluation of the design? The design is sound and well thought. The rest of this point covers some of the key aspects, critical for my use cases. The IoAwaitable protocol ======================== It solves a real problem. It is the same problem that Asio's associated properties (executor, allocator and cancellation slot) try to solve. Asio needs to stay backwards compatible though, and the adopted solutions were constrained by this fact. The IoAwaitable protocol is the robust, clean way to solve this problem. In particular: * Having child coroutines inherit the parent's io_env by default and making hops explicit with run is IMO the right thing. * Properly using symmetric transfer to avoid stack exhaustion problems is critical. This is an immense source of trouble with Asio. The Executor concept is a logical advancement on top of Asio's. * Caring about allocations is important. Providing a default that outperforms the standard allocator is equally important. * Cancellation is a first-class citizen and uses the proper primitives. std::stop_token is the right choice because: ** It is thread-safe by default. Asio's cancellations aren't thread-safe by default. I can't count the number of users having bugs due to this when using mysql::connection_pool. ** It is stateful. Asio's cancellations aren't stateful by default - you need to explicitly store the fact that a cancellation was received, one way or the other. This results in you having to check for cancellations before each initiation, a common source of bugs. You don't need to do this with Capy/Corosio. ** There is a single cancellation type (against Asio's terminal, partial and total). This added IMO unnecessary complexity. * Work counting is acknowledged as something important. I wonder however whether the Executor concept is the right place for the work counting functions to be. Work counting looks like the responsibility of the execution_context, rather than the executor. Has it been considered to make these part of the execution_context interface? capy::task ========== I've used it with no problems. I appreciate the effort that has gone into optimizing it. In this line, I'd like to ask the authors whether they have any data on the cost of immediate completions when using task (rather than a custom awaitable). In Asio, immediate completions have a significant cost (as explained by Marcelo [20]). I've seen that Capy goes to considerable lengths to avoid tasks that complete immediately, making me think there is a considerable cost in Capy, too. Take read_until implementation as an example [21]. The library tries a sync completion, and falls back to creating a task only if the former fails. I think it would be useful to get some data on this. If the cost is enough, I'd like to see a utility to make the pattern in [21] usable by "Application developers" [22]. Something along these lines: task_or_immediate<int> queue::pop() { if (int v = try_pop()) return immediate{v}; return wait_and_pop(); // this returns a task } I have use cases for this in all my libraries: * connection_pool::get_connection() can complete immediately if there are unused connections in the pool. * Redis flow_controller (queue-like class) [5] can have their operations complete immediately if the queue is not empty/full (the common case). Combinators (when_any, when_all) ============================== Extremely important. In Asio, parallel_group has been experimental for years, so having a robust equivalent is critical. The architecture and semantics are sound. I would recommend adding a combinator with semantics equivalent to Asio's wait_for_one [1]. It would be similar to when_any, but cancellation would be triggered upon any task finishing, regardless of its result (whereas capy::when_any requires a successful completion to win). This can be built today with when_any, but is not very ergonomic [2]. Synchronization primitives (async_mutex and async_event) ======================== Vital for high-level libraries like Boost.Redis/MySQL. Writing co_await mutex.lock(); It clearly expresses intent. Compare it with the Asio equivalent [4]: // Claim the write lock by sending a message to the channel. Since the // channel signature is void(), there are no arguments to send in the // message itself. co_await write_lock_.async_send(); // Respond to the client with a message, echoing the line they sent. co_await async_write(socket_, "<line>"_buf); co_await async_write(socket_, dynamic_buffer(data, length)); // Release the lock by receiving the message back again. write_lock_.try_receive([](auto...){}); I would advise giving these more space in the docs, since async_event is only mentioned in the reference. I'd find useful a primitive akin to std::condition_variable, where a single waiter can be notified. I found this while implementing connection_pool in MySQL [9], where I need to wake a single "worker" when a connection is requested. I'm currently using a corosio::timer with an infinite expiry, which is a workaround. Buffers ======= Buffer sequences have a clear rationale and make vectored I/O approachable. As I mentioned in other posts, I would like to see better interoperability with std::span<Ch>, with Ch being std::byte or unsigned char. Ideally, the following should satisfy ConstBufferSequence: std::vector<std::span<const unsigned char>> This would simplify the interoperability of pure-protocol libraries with Capy. This concrete example is inspired by Postgres' COPY OUT functionality [6]. All my libraries use growable (dynamic) buffers. I initially tried to write Postgre's protocol handling code around Capy's DynamicBuffer concept and associated functions, but finally went with a custom buffer and plain read_some. The drawbacks I saw in DynamicBuffer are: * prepare(n) throws when requested more memory than the configured maximum. This is a situation that is not exceptional at all, and I manage it with an error code. * prepare(n) makes space for n bytes and returns exactly space for n bytes. MySQL and Postgres protocols feature many small messages prefixed by a byte length. I want to read at least n bytes, but I don't want to restrict myself to that - I want to pass the entire free area to read_some, to read as many messages as possible. * The library-supplied flat, growable buffers (vector_dynamic_buffer, string_dynamic_buffer) memmove their contents on every consume(). My experience is that this is an inefficient pattern, especially when dealing with many small messages. The buffer type is managed by my libraries, rather than my users, except in advanced cases. I don't think I gain much from sticking to DynamicBuffer, so I didn't. However, this may be an indication that DynamicBuffer might be a better fit for Boost.Http, rather than Capy. Error handling ============== Both libraries consistently use io_result, which contains a std::error_code. Using error codes and only error codes (vs. exceptions) is more verbose but probably the right decision. Code dealing with I/O should handle failures and cancellations, and they don't have anything of special. I'm a bit divided here, because supporting std::error_code only (vs. richer error types) makes reporting advanced diagnostics less ergonomic. Diagnostics need to be reported separately, instead of using the dedicated error channel [7]. Asio has the concept of dispositions [8]. It is a trade-off of generality vs. simplicity. All in all, I am happy with going forward with io_result. Having worked with Asio for this long, simplicity seems a good value to pursuit. Streams, sources and sinks ======= ReadStream and WriteStream are battle-tested concepts that Capy acknowledges. I've found them easy having an Asio background. I haven't come to use sources and sinks, but they look promising. For example, Postgres has a dedicated bulk copy protocol to transfer entire tables to/from the client, where they could fit: connection::copy_to_client(std::string_view copy_sql, WriteSink& dest); Allowing type erasure is a big improvement over Asio, as it allows shipping compiled libraries and hence cutting build times. I've found myself almost always using the non-owning version of any_stream, as I want to re-use my I/O objects across reconnections, and you need the concrete stream type to perform connection establishment. Transfer algorithms =================== I use capy::write() profusely - having it is a must. My use case (length-prefixed message protocols) looks like a good use case for capy::read (plain buffer version). Actually, the reference section lists this use case as example [18]. I'm not sure this pattern is efficient, though, as with most streams in Corosio you'd be running two syscalls per message. As an improvement, I could implement a wrapper stream that buffers bytes (à la Asio's buffered_stream [19]), but manual handling looks simpler to me. Also, read() returns a task, which I understand has overhead even when it completes immediately. I would consider whether capy::read() and capy::read_until() are really necessary at this point, as pointed out by other reviewers. Corosio io_context ================== I've always liked Asio's io_context, and I like seeing a proper io_context implementation here (vs. just capy::thread_pool), as it lets the user much more control. I'd like to see documented better what guarantees can I expect from executor affinity, especially when using multiple threads. My understanding is that executor affinity here does not buy thread affinity, and that coroutines may resume in any of the threads calling io_context::run() (like in Asio). This piece of documentation [10] states that the strand problem is mostly solved through executor affinity. This happens in Asio too ("implicit strand" IIRC), but has _many_ loose edges. Take the Asio's equivalent from [10] as an example: asio::awaitable<void> session(tcp::socket sock) { // All code in this coroutine runs sequentially auto [ec, n] = co_await sock.async_read_some(buf, asio::as_tuple); // No other code in this coroutine runs until above completes co_await sock.async_write_some(response, asio::as_tuple); // Still sequential } This is safe without strands even from multiple threads. However, if I now set a timeout with cancel_after, this is no longer safe because we have two parallel execution chains (async_read_some and the timer): asio::awaitable<void> session(tcp::socket sock) { // Race condition and UB auto [ec, n] = co_await sock.async_read_some(buf, asio::cancel_after(10s, asio::as_tuple)); } My understanding is that Capy/Corosio have gone a step further, and that this is safe: capy::task<void> session(corosio::tcp_socket sock) { // Safe on a single-threaded io_context auto [ec, n] = co_await capy::timeout(sock.read_some(buf), 10s); } If that's the case, having it documented would help IMO. As well as where the limits of this pattern are. For instance, I understand that the parallel fetch pattern proposed in the Capy docs [11] would require strands. So would a websocket connection that reads and writes data at the same time (even when using the "One Coroutine Per Connection" pattern [12]). A mention to capy::strand would be beneficial, since the docs seem to imply that strands are just superseded by executor affinity, which I don't think it's true. What's the behavior if I use more threads than the concurrency_hint passed to the constructor (with concurrency_hint != 1)? Corosio I/O objects only work with corosio::io_context. This may come to a surprise if you come from an Asio background, because asio::thread_pool works with all I/O objects, but capy::thread_pool does not. I'd advise mentioning this in the docs. Corosio sockets =============== I'm happy to see TCP and UNIX sockets, without templates and with semantics matching Asio's. I have had no problems using them. I was a bit surprised to see the io_stream interface [13], as it somehow looks to overlap with capy::any_stream (you may do polymorphism using both). The implemented functionality covers all my present use cases, but I think it may fall short on extensibility. There are _many_ socket types [14], most of them with very niche use cases. The library makes the right decision to support the most common subset. But it'd be good practice to provide an extensibility mechanism to allow users to interact with whatever socket types they may need ("open-closed principle"). For example, a stream_socket/datagram_socket base class may be provided. The native types indicate real industry needs and are a sign that the library is facing real use cases. They are however not covered in the docs. As I mentioned in previous posts [16], current utility of the tcp_socket::wait() function is limited. It is aimed at integrating with non-blocking C libraries, but many of these supply you with a file descriptor that you should poll. But there is no tcp_socket::assign() function to achieve it. My advise here would be removing the libpq example from the docs [15], as it is not implementable, and re-think how the integration would look like. I don't think copying Asio is the best choice here, as it leads to messy, brittle code [16]. I don't think this is core functionality though, and may be deferred as required. I found the tcp class surprising. It makes sense in Asio because sockets and acceptors are generic and templated on the protocol. This is not the case in Corosio. I recommend replacing the class by an enum. I found acceptors easy to use coming from an Asio background. I found tcp_server odd at first, but useful. My only suggestion would be to consider extensibility as mentioned above (having common code could simplify having a local_stream_server, for instance). DNS and connection establishment ================================ Again, simple enough. I'd consider making resolver_entry and reverse_resolver_result aggregate types. Having range connect is important. Is there a reason for supporting iterator-based overloads in C++20 (as opposed to using std::ranges::subrange [17])? Corosio timers, capy::timeout() and capy::delay() ================================================= There is a lot of overlap between capy::timeout, capy::delay, corosio::timer, corosio::cancel_at and corosio::cancel_after. First, there is need to have a robust way of waiting and setting timeouts to asynchronous operations. I use these two primitives heavily in all my libraries. They need to be provided, in one way or another. Second, I don't know if having these primitives in Capy is a good option. On the one hand, timeout() seems a foundational primitive, useful in almost all contexts, even those without I/O. On the other hand, timeouts are better implemented in the presence of a reactor. Having them in Capy, with today's architecture, implies an extra thread, at the very least. It is also not clear to me whether capy::timeout() and capy::delay() are safe to use with io_context with a concurrency_hint of one. Third, I find delay() and timeout() ergonomics much better than Asio's timer interface. They are stateless and express intent much better. I have been pointed out by Vinnie that they imply an extra allocation though [23]. My understanding is that this could be avoided by making the functions live in Corosio, even with the stateless API, so I'd recommend going down this path. I suspect one of the reasons for Asio's stateful timer interface is supporting cancellation, since timers predate per-operation cancellation (by a lot). While timer::cancel() is superseded by the stop token in io_env, timer::cancel_one() is not. I use the latter as a synchronization primitive [9]. I don't think that we need timer::cancel_one(), but a proper synchronization primitive that allows waking a single waiter (as opposed to async_event::set). capy::timeout() is missing an overload taking a time_point (equivalent to cancel_at [3]). TL;DR: my recommendation is to move timeout() and delay() to Corosio, remove timers and cancel_at/cancel_after, and implement a synchronization primitive in Capy akin to std::condition_variable. TLS === I have been able to use it effectively. I appreciate the effort to decouple the interface (tls_context and tls_stream) from individual libraries, as it makes it much easier to avoid hard dependencies. I appreciate having a function to set SNI (tls_context::set_hostname [24]), but I think it should be a member of tls_stream, rather than tls_context (matching what OpenSSL does [25]). Issue in [26]. I miss a way to access the native TLS context/stream handles. This is useful if you know that you're using a particular library. The OpenSSL API is huge, and Corosio doesn't (and shouldn't) provide support for most of it. Yet, it should provide an escape hatch for users that do need any of these options. My concrete use case here was using SSL_CTX_set_keylog_callback [27] to enable traffic visualization for a particular issue that only happened with TLS. Corosio should _not_ support this option, but allow an escape hatch to set it without modifying Corosio's source code. The current implementation has still some gaps [28] that should be filled before Boost acceptance. Note that I've used tls_stream with non-owning any_stream values only. I want to re-use the stream object (with tls_stream::reset). As part of a reconnection, you need to perform transport-level connection (tcp_socket::connect), which any_stream doesn't support. Casting any_stream objects is also not possible, because the type-erasing technique doesn't use inheritance. For this reason, I think that tls_stream::next_layer() is not really useful and should be removed. Asio integration ================ I think that this is an important topic and it is currently missing from the library. For me, a seamless Asio integration allows me to ship only a Capy/Corosio implementation in my libraries. Not having it forces me to ship two APIs until Capy/Corosio are sufficiently adopted. Ideally, users should be able to start using a Capy/Corosio-based library in their Asio applications without a full migration. 3. What is your evaluation of the implementation? I included all I had to say about the implementation in the corresponding point above. I haven't conducted an exhaustive review of the implementation, but peeked around the components that I have used. 4. What is your evaluation of the documentation? I miss the guarantees that Corosio's I/O operations give me upon cancellation. For example, if I run: tcp_socket sock; // ... connect the socket auto [ec, bytes] = co_await capy::timeout(sock.read_some(buff), 1s); And the operation is cancelled due to the timeout firing, what state is the socket left in? Can I issue another read_some operation, or do I need to close the socket and connect it again? I suggest using Asio's cancellation types (terminal, partial, total [29]) as cancellation guarantees. Note that I'm not suggesting adding support for requesting a particular cancellation type like in Asio, but to use these same terms to describe what to expect after a cancellation happens. I find the "Introduction to Concurrency" [30] section of the docs surprising, as it is not really related to the library. I'd move it to an annex. Some minor points: * These Corosio examples look like a good case for range connect: https://master.corosio.cpp.al/corosio/4.guide/4j.resolver.html#_connecting_…, https://master.corosio.cpp.al/corosio/3.tutorials/3c.dns-lookup.html#_conne… * I'd advise recommending std::ranges::filter (rather than ConnectCondition) for this example: https://master.corosio.cpp.al/corosio/4.guide/4d.sockets.html#_filtering_ca… * I'd advise to use C++20 std::jthread in the documentation and examples, rather than std::thread. * tcp_server::start() docs mention providing workers to the constructor (should be to set_workers, instead). 5. Have you used either or both libraries? What was your experience? I have written a Boost.MySQL Capy equivalent [31], a Corosio API for Boost.Redis [32] and a Postgres library [33] (still a work in progress). I have already described my experience above. 6. Are the libraries ready for inclusion in Boost? If not, what changes would you recommend before acceptance? My recommendation is to CONDITIONALLY ACCEPT Capy and Corosio into Boost, provided that: * Asio integration is properly implemented. * The delay/timeout/timer interface is redesigned. * The TLS implementation gaps are filled. Kind regards, Ruben. [1] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/experim… [2] https://master.capy.cpp.al/capy/4.coroutines/4f.composition.html#_errors_do… [3] https://master.corosio.cpp.al/corosio/reference/boost/corosio/cancel_at-02.… [4] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/example/cpp20/cha… [5] https://github.com/boostorg/redis/blob/corosio/include/boost/redis/detail/f… [6] https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-COPY [7] https://github.com/anarthal/nativepg/blob/b33026688885475538a07222b6639a1ed… [8] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/Disposi… [9] https://github.com/anarthal/mycosql/blob/485bb4ec932955f4256e1ac65bc95395a6… [10] https://master.corosio.cpp.al/corosio/4.guide/4b.concurrent-programming.htm… [11] https://master.capy.cpp.al/capy/8.examples/8g.parallel-fetch.html [12] https://master.corosio.cpp.al/corosio/4.guide/4b.concurrent-programming.htm… [13] https://master.corosio.cpp.al/corosio/4.guide/4d.sockets.html#_the_io_strea… [14] https://man7.org/linux/man-pages/man2/socket.2.html [15] https://master.corosio.cpp.al/corosio/4.guide/4r.wait.html#_wrapping_a_nonb… [16] https://lists.boost.org/archives/list/boost@lists.boost.org/thread/OPE4XC5N… [17] https://en.cppreference.com/cpp/ranges/subrange [18] https://master.capy.cpp.al/capy/reference/boost/capy/read-00.html#_example [19] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/buffere… [20] https://github.com/boostorg/redis/blob/develop/doc/on-the-costs-of-async-ab… [21] https://github.com/cppalliance/capy/blob/9144290189fa149b27617c7d9a476c8fbf… [22] https://isocpp.org/files/papers/P4172R1.pdf [23] https://github.com/cppalliance/capy/blob/9144290189fa149b27617c7d9a476c8fbf… [24] https://master.corosio.cpp.al/corosio/4.guide/4l.tls.html#_hostname_verific… [25] https://docs.openssl.org/3.3/man3/SSL_CTX_set_tlsext_servername_callback/#d… [26] https://github.com/cppalliance/corosio/issues/239 [27] https://docs.openssl.org/3.3/man3/SSL_CTX_set_keylog_callback/ [28] https://master.corosio.cpp.al/corosio/4.guide/4l.tls.html#_overview [29] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/overview/core/can… [30] https://develop.capy.cpp.al/capy/3.concurrency/3.intro.html [31] https://github.com/anarthal/mycosql [32] https://github.com/boostorg/redis/pull/417 [33] https://github.com/anarthal/nativepg

3 4

Invalid memory read in io_context::executor_type::post
by Ruben Perez 29 Jun '26

29 Jun '26

Hi all, The continuation version of io_context::executor_type::post [1] seems to cause an invalid read when submitting operations that don't inherit from continuation_op. try_from_continuation [2] will attempt to read a magic number. In continuation_op, the magic is before the continuation member [3]. If the submitted operation doesn't inherit from continuation_op, this leads to reading potentially unmapped memory. Reproducer (build with -fsanitize=address): struct my_awaitable { capy::continuation* cont; bool await_ready() const { return false; } std::coroutine_handle<> await_suspend( std::coroutine_handle<> h, capy::io_env const* env) noexcept { cont->h = h; env->executor.post(*cont); return std::noop_coroutine(); } int await_resume() const { return 42; } }; capy::task<void> co_main() { auto cont = std::make_unique<capy::continuation>(); my_awaitable aw{cont.get()}; int v = co_await aw; std::cout << "The value is: " << v << std::endl; } I've also raised an issue in the repo [4]. [1] https://github.com/cppalliance/corosio/blob/4276bd4039097fd4dd62dda4bb55e53… [2] https://github.com/cppalliance/corosio/blob/4276bd4039097fd4dd62dda4bb55e53… [3] https://github.com/cppalliance/corosio/blob/4276bd4039097fd4dd62dda4bb55e53… [4] https://github.com/cppalliance/corosio/issues/290

2 1

[Capy/Corosio review]
by James Earnshaw 29 Jun '26

29 Jun '26

This is my formal review of the Capy and Corosio Libraries. As context I have been working with the Capy and Corosio libraries for a period of four months as part of a coroutine migration effort. I have been involved in implementing various components of, and applications within a tier-1 financial market system (deployed on Linux) that has been in production for many years. The platform currently uses Asio as an IO backbone, so using a library that mirrors the behaviour and performance of the Asio counterparts was important. While this review is about the merits of Capy/Corosio, it is natural that much of it may reference Asio as a comparator given that it is our reference point for capability and performance given our existing codebase is entirely based on the Asio library (largely using callbacks). Also note I come at this review from the position of a user picking up a new library as part of a refactoring and navigating that library based on the documentation and examples provided. I’m not trying to do anything too clever and have been able to fall-back on existing tests to assure behaviour (albeit updated to work with Capy/Corosio). *1. What is your evaluation of the usefulness of the libraries?* My goal, by using these libraries, was to build simple coroutine scaffolding around pre-existing concepts within the codebase. This was made possible by a familiar API and strong documentation. The introductions provided a good high-level overview that allowed me, given my limited knowledge and experience with coroutines, to get up to speed quickly. These libraries will prove very useful for building effective coroutine-based applications. I have used capy and corosio to write TCP/UDP servers and clients using each of the socket types, so the facilities provided by Corosio are exactly what I would expect from a networking library. As an aside I should note that all my previous experience has been with Asio and callback code so while some may feel that style of code is hard to reason about I find it more intuitive, mainly because of my experiences to date. This means, for example, that some coroutine specific patterns felt a little clunky or counter-intuitive at first. Not long after my first introduction to the libraries I attempted to rewrite some functions that execute a callback periodically when an asynchronous timer expires. This was when a new pattern was adopted: the periodic callback needs to be run in a loop, since the alternative, re-entering the same timer function indefinitely could result in a stack overflow. For me, initially, the callback style code felt easier to reason about. I had a similar experience when refactoring server code that performs read and write tasks. While the new pattern of performing the asynchronous waits in a loop made the flow of the server easier to understand from a high-level perspective, doing this as part of a callback-chain felt more natural to me. Why am I mentioning this as a general observation? Well because, as someone who might be more representative of a typical user coming from a callback-based Asio background they may face similar mental hurdles. However, and this is the point, despite this: the mental jump from callbacks to coroutines and then using a new library as well, I can say that the experience has been a good one. So none of this is a criticism, more just an observation that may lead to documentation improvements to better aid users like me. No doubt there will be alternative patterns and approaches I should have taken but I haven’t looked into that in detail yet because I was able to get code working that delivered the same or better performance than the older implementation by using the documentation as a very accessible guide. *2. What is your evaluation of the design?* The design of the library has been easy to use with limited background knowledge of C++20 coroutines. In terms of the facilities from Capy, having the capy-provided task type meant that coroutines could be composed and executed in parallel to make up small working projects with only few includes required. Using run_async in more complicated code took some getting used to, in comparison to my experience of Asio’s callback approach using, for example, boost::asio::read_some( Socket, Callback ) where the execution of the async operation is also the code that runs after the operation is complete and no more than that. Passing stop tokens through the coroutine stack automatically in the background makes cancellation a seamless task. Running child tasks within this stack is easy to orchestrate with the helpers e.g. capy::this_coro, for getting access to the environment where the stop token can be found. So all-in-all, as advertised, this is more or less a familiar design to Asio but with a focus on being coroutine-first. *3. What is your evaluation of the implementation?* My experience of the libraries is less of the implementation and more of the usage of the API, so I haven’t read a lot of the source code. Anecdotally from a testing and behavioural point of view clearly the implementation is fit for purpose as all of our tests (refactored to allow both Asio and Capy/Corosio variants) passed and performed comparably or better, so no concerns here. *4. What is your evaluation of the documentation?* The documentation is incredibly strong. The way they begin from first principles - networking, coroutine machinery and threading synchronisation etc., means that C++ developers can reference the documents for guidance on many related topics. A lot of canonical patterns are given. I found it was a simple task to adapt these to working code. *5. Have you used either or both libraries? What was your experience?* Yes, as noted, I have used both libraries for a period of about 4 months to-date. Prior to that I had no experience of working with coroutines in C++. As a result I very much appreciated that the documentation started from first principles of coroutines, allowing me to write my own awaiters and promises to get a handle on the machinery, before trying some of the same mock code with capy task and run_async. Creating my own awaiter involved creating a sleeping thread that then posted the continuation on wake-up. To get this working I had to look at the capy::delay_awaitable to see what was done with the handle and io_env, so maybe the documentation could be improved for others wanting to create their own. In trying to write more complex code I was tripped up by the lambda capture lifetime caused by temporary lambda tasks on multiple occasions. However the documentation has since been updated and explicitly warns users about this with sufficient detail to explain exactly what happens in this scenario, and proven alternatives. In the time I have been using Capy/Corosio the documentation has continued to evolve as misunderstandings arise and can be addressed and this has supported (for me) a positive experience of using the libraries but more importantly the result of using the libraries has been working, production quality code. *6. Are the libraries ready for inclusion in Boost?* Yes, the libraries are such that they provide all of the tools necessary to write coroutine code with networking facilities. For my use cases there is just one point to be made about the socket/endpoint interfaces which is mentioned below. In short, for Asio, we write resolver.resolve(host_name, port) and then try each of the endpoints, each of which is potentially IPv4 or IPv6, until one of them works, keeping the application code independent of the particular IP version. In some cases, it would be convenient if corosio supported a similar mechanism that would replace this style of application code: if( Endpoint.is_v4() ) { Socket_.set_option ( boost::corosio::socket_option ::join_group_v4( Endpoint.v4_address() ) ); } else { Socket_.set_option ( boost::corosio::socket_option ::join_group_v6( Endpoint.v6_address() ) ); } with Socket_.set_option( boost::corosio::socket_option::join_group( Endpoint ) ); Having said that, this is not a blocker. I haven’t looked into the test coverage on these libraries so cannot make any comments about this. *7. If not, what changes would you recommend before acceptance?* Nothing that would be considered a blocker. *8. Do the libraries fit well within the existing Boost ecosystem?* Yes, as a C++20 coroutine-first alternative to Asio. Capy in particular could serve as a basis for other IO library developers wishing to start from a foundation of coroutines if it was accepted alone (recognising that the review is to treat both libraries as a set). *9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed?* I have no major concerns about the libraries. The authors have been quick to address and fix any issues encountered with use. Our code would directly depend on native support for websockets. I have been told that this will be supported at a later date, but I cannot find any github issues or timelines backing this up. *Summary* For the avoidance of doubt I vote to accept these libraries into Boost on the basis that for my use cases they have proved fit for purpose. I have no strong views on the APIs and proposed changes voiced in other reviews as I’ve been tracking an evolving API for a while now and have not encountered any blockers.

2 1

[Capy review] On benchmarks
by Ruben Perez 29 Jun '26

29 Jun '26

Hi all, I've been reading the benchmarks page in Corosio (https://master.corosio.cpp.al/corosio/benchmark-report.html) The coverage seems quite impressive. I've found a case ("socket bidirectional throughput") where Corosio seems 2 times slower than Asio (https://master.corosio.cpp.al/corosio/benchmark-report.html#_socket_io) Do we know what's the reason behind this? Would fixing it require significant architectural changes, or minor ones? Thanks, Ruben.

2 1

B2 5.5.0 release
by René Ferdinand Rivera Morell 28 Jun '26

28 Jun '26

FYI, the latest (5.5.0) release of B2 is now in the develop branch. It will get to the master branch in the next couple of days if nothing blows up. For what's in the release see: < https://github.com/bfgroup/b2/releases/tag/5.5.0> -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

1 0

[capy review] Klemens' Laundry list
by Klemens Morgenstern 28 Jun '26

28 Jun '26

Disclaimer: I have been involved in the development in affiliation with the C++Alliance. I wish to first of all express that I really admire the effort of creating a coroutine-first alternative to boost.asio that can optimize run- and compile-time by having only one asynchronous completion mechanism. However, I fear that capy & corosio are not ready. Below is a list of criticisms & issues that might end up as part of my review. However, I think it is better to allow the authors to address these first. I have discussed some of these with Vinnie on Slack already, but I think it is better to get this on the record for the review. So I hope he doesn't mind reiterating some of the discussion we had. # 1. Comparison to asio Asio is incredibly feature-rich and I would not expect capy/corosio to match all the features. However, I would hope it to would more features or different approaches, that take the coroutines into account. However, they are mainly compile and run-time improvements and very little in functionality. Since `capy::task` is functional equivalent to `asio::awaitable` the only thing I can identify are the type erased streams (e.g. any_read_stream) and the ability to use different SSL implementations like wolfSSL. The type-erase stream types however are then not even used, the corosio::read_until function is templated. Their ownership semantic (construction by pointer is non-owning, construction by pointer is owning) is very unintuitive. Construction by lvalue ref is non-owning, by rvalue ref is owning would make more sense to me. As a side-note: Botan actually offers a SSL stream for asio, so technically other SSL implementations for asio exist. Other than that there seems to be a lot of "asio did it" design decisions. ## 2. capy::continuation The continuation type is useful because the executor doesn't need to allocate a list on it's own, it uses an intrusive list of which `continuation` is a node. However, the `next` member is public and default constructed as null. If this was an implementation detail, why isn't it private? Or at least name `next_` or `_next` ? It could be public and allow me to submit multiple continuations at once, but as it is, it is an odd api. At the very least I would expect a non-explicity constructor from a `coroutine_handle`. It is an implementation detail leaking out for no apparent reason. ## 3. capy::async_mutex The mutex is a thing that's not thread-safe. This naming is just bad. And no, it's not enough that it's documented, as this is very counter-intuitive. ## 4. capy::DynamicBuffer / capy::read_until The dynamic_buffer concept comes from asio and I don't think it is needed in a coroutine library. It's one of the "asio did it" features. The reason asio has those is because of `async_read_until`. In asio, writing an asynchronous algorithm is extremely painful, so using `async_read_until` is a massive help. However, once we have coroutine, this becomes a `for` loop. std::string buffer; auto [ec, n] = co_await read_until(s, capy::dynamic_buffer(buffer), "\n", 2048); Can be written as : std::string buffer; while (buffer.find('\n') == std::string::npos) { const auto prefix = buffer.size(); buffer.resize(prefix + 2048); auto buf = capy::make_buffer(buffer); buf += prefix; auto [ec, n] = co_await s.read_some(buf); buffer.resize(prefix + n); if (ec) co_return ec; } From my experience using asio for years, I can also say that I almost never used read_until. It usually ended up being replaced because the matching function wasn't ideal for many protocols. Mainly because the matching condition (as it does in capy' read_until) always rescans the whole buffer. Even in the example above it would be more efficient to pass `prefix` after find to not scan through the whole string again. I would also like to add that beast is providing it's own buffer types to use with it's http functions. Dynamic Buffers may be a good idea for certain protocols, but it is not at all evident to me that they make a good generic concept. Rather I think that a dynamic buffer should be optimized for it's protocol. But, because we have `read_until` we now replace 10 lines of code with multiple types and concepts that I consider unnecessary. It seems yet another design decision based on "asio did it" that doesn't seem to have reevaluated the changed conditions. ## 5. capy's non dynamic buffers First of all, I agree with asio's decision to use a pair of `void*` and `size_t`, because memory is untyped. So those two are correct. However, it seems capy is copying `asios` buffer sequence without reconsidering the following new circumstances: If I have a function accepting a `span<const_buffer>` and I have a generic buffer sequence I could do this: some_buffer_sequence bs; co_await write(s, as_span(bs)); Where span returns a type that can be converted to the span. Because the `co_await` expression is - as one might guess - an expression, the lifetime of the container referenced by the span will be destroyed after the coroutine is returned. Thereby we could avoid templating the write function over the buffer sequence and reduce compile time and complexity. An IO object could also communicate through it's API if actually supports vectorized IO or not. The buffer types could also just wrap around the OS buffer types (e.g. iovec) and thus avoid any copying. If a stream does not get templated on the buffer_sequence, but just takes a span, implementation of other stream types gets much simpler, too. This is important if capy wants to establish it's stream concepts as the de-factor or actual standard. To be clear: I am not saying that a `span` is the right solution, but there are simpler solutions that can have a concrete type. Asio's buffer sequences need to work with asynchronous completion that do not get `co_await`ed and thus has to solve lifetime problems, that capy hasn't. The design of capy does not seem to consider this subtle difference. ## 6. capy::any_executor I don't understand why there's an `executor_ref` and an `any_executor`. If the `any_stream` support non-owning mode, why couldn't the `any_executor` follow the same model and we don't have an `executor_ref` ? I know that `executor_ref` is uses in the tasks and must be cheaply copyable, but why couldn't that use a single any_executor at the structure allocated by `async_run` and then a `any_executor&` in the task. At the very least, there's an inconsistency between `any_executor` and the `any_stream` types. ## 7. capy::execution_context Next, the `capy::execution_context` is odd. It is only used by `corosio`, however it is part of any `executor`. However, it turns out that the `execution_context` can be default constructed but is completely useless unless constructed as the parent class of corosio::io_context? Why is that? In asio, I can default construct an `execution_context` and it'll spawn off a thread for the reactor and it'll work great. Likewise the `asio::thread_pool` will work, where as capy::thread_pool will not allow me to create a corosio::tcp_socket. If the `execution_context` must not be used this way, the constructor should be `protected`. I would very much prefer it behaved like `asio`, because that is required to make the asio bridge I wrote work. ## 8. capy::IoAwaitable The IO awaitable protocol is an interesting idea of how to solve the executor propagation problem. However, it has one issue: not every waitable is asynchronous. That means that not every awaitable will need to dispatch back through the executor. I think restricting `co_await` to just `io_awaitables` is too restrictive and puts `capy::task` as `asio::awaitable`. I don't think that proposing io_awaitable for the standard is an argument either, since at this point regular `awaitable`s are the standard protocol. I don't know how capy should fix it, but this is a missing feature, if `capy` wants to a generic coroutine library. `asio::awaitable` achieves a similar thing, by only allowing `asio::awaitables` to await each other. That is fine, but it turns a `capy::task` into something more specific, a coroutine type aimed towards use with corosio. ## 9. capy::async_run The `async_run` double invocation just looks weird. I get the intention of setting the thread_local memory resource for when the task is created. I do however think that this is a consequence of `asio did it` design. This could be much more intuitive, if the `corosio::io_context` API changed to this: // we use a main task that can use wait_all & wait_any to manage other work capy::task<double> main_task(); { corosio::io_context ctx; double res = ctx.run(main_task()); } We would achieve two things: we got rid of the callback, which is generally a good idea in a coroutine library, and we could bind the memory_resource to the io_context. This would give us a simpler and much more intuitive API and an implicit work guard with the `main_task`. But alas, capy/corosio just copies `asio`'s API for `io_context` and requires a call to `run`; ## 10. capy::io_result `io_result` is not great, because std::get<> is not an extension point. That means I can't use `std::tie`. The code examples use structured binding for the `error_code`, but that means I will need to redeclare `ec` for every operations. const auto [ec, nr] = co_await read_some(...); const auto [ec2, nw] = co_await write_some(...); This needs to be solved.

3 2

[Capy review] On peer dependencies
by Ruben Perez 28 Jun '26

28 Jun '26

I'd like to bring up the issue of peer dependencies in Boost, taking Capy's review as an occasion. Running boostdep --brief capy yields: # Primary dependencies asio # Secondary dependencies align assert # and half of Boost, omitted for brevity This is not a hard dependency - Asio is included in an optional header (capy/buffers/asio.hpp) to facilitate integration. I think this is the right choice, but we lack a way to represent this. Every Boost library depending on Capy and using boostdep will now install Asio and half of Boost (when they likely don't need it). I don't know if this has implications for package managers or not (the b2 people probably know the answer). What's everyone's opinion on this? Should we try to do something to represent the concept of "peer dependency"? (maybe a field in meta.json?) Best, Ruben.

6 13

[release] 1.92.0 Deadline for major changes is next Wednesday!
by Marshall Clow 27 Jun '26

27 Jun '26

We’re starting the 1.92.0 release cycle. Upcoming milestones: 1-Jul - Boost 1.92.0 closed for major changes 8-Jul - Boost 1.92.0 closed for beta As always, you can find the calendar here: https://www.boost.org/calendar/ — The release managers

2 1

[Capy Review] Why no default rescheduling?
by Marcelo Zimbres Silva 26 Jun '26

26 Jun '26

Hi, there seems to be a fundamental difference between how Asio and Capy protect its users against async operations that are always ready. Asio uses default rescheduling and will not call the continuation inline even if the completion is synchronous. This is valuable for the safety of internet facing code e.g. a malicious client can't starve other tasks by sending data continuously. Capy on the other hand uses symmetric transfer to deal with synchronous completions, allowing the task to monopolize the event loop as long as data is available. IMO it is not safe enough to delegate yielding into the event loop to users as forgetting to do so creates vulnerability. It is safer to provide a way out of default rescheduling than requiring every user to do it manually. The problem is not a theoretical one and widely used runtimes such as Tokio had to correct course to avoid it [1] > If data is received faster than it can be processed, it is possible that more data will have already been received by the time the processing of a data chunk completes. In this case, .await will never yield control back to the scheduler, other tasks will not be scheduled, resulting in starvation and large latency variance. > Currently, the answer to this problem is that the user of Tokio is responsible for adding yield points in both the application and libraries. In practice, very few actually do this and end up being vulnerable to this sort of problem. I would like to know why Corosio/Capy authors decided to take this direction? Marcelo [1] https://tokio.rs/blog/2020-04-preemption

2 1

Capy & Corosio Review
by Jonny Weir 26 Jun '26

26 Jun '26

This is my formal review of the capy and corosio libraries. This review of capy and corosio is based on 4 months of active development on a large-scale production codebase which consists of a total of 56 repositories in a standard platform release, of which 39 form part of the C++ framework, all of which use asio for their underlying asynchronous implementation. Of those, 7 repositories contain more concentrated use as part of the message passing architecture by providing core pipeline and transport layer utilities. The codebase in question is for a tier-1 financial market system that has been in production for many years. The codebase builds using gcc15, supporting C++23/26. It is worth noting that this review has been written with the view that capy/corosio is used to underpin the backend asynchronous operations and networking. No attempt was made to have asio/corosio interoperability. I have framed my review around the original questions proposed by Jeff Garland. 1. What is your evaluation of the usefulness of the libraries? In a high performance, ultra low latency environment, being able to move data around efficiently is of the utmost importance. The capy library is extremely useful for this. It has a very specific set of functionality: coroutine tasks, buffers, streams, and executors. This makes it easy to reason about where it fits into an existing codebase, or how it is to be used for a new project. Equally, the same can be said about corosio, fast and efficient networking is core to the functioning of financial systems. Having a modern approach to network programming is extremely useful. 2. What is your evaluation of the design? Having actively used this library for the last 4 months, I can say with confidence that capy is a well designed library. By separating out buffers, streams, and executors, capy gives the user orthogonal abstractions. That is to say, memory layout, asynchronous byte transfer, and coroutine scheduling can be mixed and matched, optimized independently, tested in isolation, and reused without pulling in platform specific networking or each other's implementation details. A key design decision is that it is coroutine-only. This has not been retrofitted and therefore commits to one single asynchronous style. The usual benefits of coroutines apply: flow control reads as sequential code. The use of capy primitives (eg: run_async/when_all/etc...) are used instead of ad-hoc callback chains. Corosio provides a layered design (similar to capy) that consists of three layers: (viewed as native vs. type-erased) - abstract - eg: io_stream, type-erased and generic that works with TCP/UDP/Unix domain socket/etc... - concrete - the full protocol API (connect, bind, endpoints, socket options) for each type. - native - implementation specific inlined awaitables with no vtable. The corosio design focuses on IO primitives, sockets, resolvers, timers, etc... and does not try to be an execution framework. This results in a cleaner codebase with clear ownership of problems, all of which can be paired very naturally to specific networking problems, like HTTP, or Websockets. By using the capy::io_result<T>, there is a consistent way to handle errors and results. It is the same for sockets, resolvers, timers, etc… 3. What is your evaluation of the implementation? The capy and corosio implementations use modern C++20 techniques: - concepts - coroutines - structured bindings - std::stop_token - PMR-style allocators I have spent some time inside the capy source (mostly when it came to raising bugs/issues/questions) and I found that there is a clear layered design without platform coupling. The layered design provides clear separation points within the code: executor / run_async -> where and when coroutines resume | v streams / sources/sinks -> the async byte transfer semantics | v buffers / buffer sequences -> memory regions those operations use Users are able to choose the layer as per their need, for example: - Protocol parsing - BufferSink / BufferSource concepts (zero-copy). - Connection logic - concrete stream types (or the type-erased any_stream&). The higher-level behaviour is typically expressed as template free functions that are constrained by concepts. Capy keeps concepts (compile-time contracts) and wrappers (runtime polymorphism) as separate layers, so you choose where the cost lands (native vs. type-erased) . This approach to implementation gives the user full control over how they integrate capy into their projects. It is also worth mentioning that a lot of the capy and corosio specific compile errors that were seen were easy to follow and debug. It was rare to see pages of obscure compile-time errors with little or no information about what actually happened when the capy/corosio related code was incorrect. The corosio implementation has a very familiar look and feel, borrowing much of the styling from well established asio principles. Many of the APIs are very similar to asio. As a result, the biggest challenge was thinking about the coroutine integration, rather than having to re-think the applications network stack and how it behaves. The capy and corosio source code quality is very high. When it came to requesting features, an attempt was made to understand how things currently work before offering up a solution, or, to check whether it was feasible or not. The code was easy to read and understand. A number of bugs were fixed and features added during this large-scale refactoring project. I found error handling to be very consistent across the library. The structured binding approach is used everywhere and io_result never throws, which is extremely important for the code I work on. However, it is possible to throw std::system_error(ec) if that behaviour is desired. From a performance and benchmarking perspective, the implementation (epoll in this case) is performant. It is on a par with asio under production-style loads and it is definitely capable of low latency message handling (more on this later). Having the option to use fully inlined backend calls without introducing a second, parallel type hierarchy or a separate way of thinking about sockets and streams is a very attractive implementation detail. 4. What is your evaluation of the documentation? This was my first real foray into the world of coroutines and how they might be used in a production codebase. I am familiar with C++20 coroutines, but I had no real world experience with them. The capy documentation gives a very good primer and introduction into coroutines, concurrency, and all of the associated concepts. I found the documentation clear, and easy to follow. I have a lot of experience with asio and reading through the capy documentation allowed me to see the similarities between capy and asio (in terms of buffers) and map them directly onto pre-existing concepts that were lifted from asio, no discrepancies in terms of what I would expect the behaviour to be were noticed. For the new concepts introduced by capy, each section is well presented and clearly written. The code examples are concise and go to great lengths to illustrate most (all?) of the functionality. It was rare that I would not find what I was looking for when looking over the specific examples if I was unclear on how to do something. If details were missing, the authors made the required documentation updates. As an experienced user of asio, my view on the corosio documentation is that it is very well written and explains each of the concepts very clearly. Users who have asio familiarity will be very comfortable with this documentation. As for users who may not be familiar with network programming, or asio, they will get a gentle introduction with a number of tutorials that are well written and include code examples that are well commented. New users should be able to get up to speed quickly, given the quality of the documentation. 5. Have you used either or both libraries? What was your experience? As mentioned above, I have been using capy for 4 months now on a large-scale production codebase that is underpinned by asio. The goal of the project was to assess the viability of capy/corosio as an alternative to asio. The asio code in question used lambda-style callbacks and in some places, asio (stackless) coroutines, as well as various uses of timers, buffers, and asio specific helpers for various networking functionality. The first major piece of work was to integrate capy into the core message passing pipeline library that underpins the entire codebase. A traits based approach was taken which facilitated using asio_traits or capy_traits as the backend. This was configured as a compile-time option. The system could be built with asio or capy. A springboard approach was taken that wraps a callable with all of the required coroutine machinery and is then executed inline, or posted across a thread boundary. This integration was relatively unintrusive aside from the compile-time defines that needed to be specified in a small number of places. Even when capy moved from a std::coroutine_handle to a capy::continuation model, the traits based approach was easily modified to handle the continuation based approach. Part of the goal with this springboard approach was to avoid changing core infrastructure. Whilst the implementation may not have been as optimal as it could have been, the performance was still very comparable to the asio equivalent. This traits based approach resulted in a very minimal set of boilerplate code to determine which implementation was used at compile time. This boiled down to a number of defines being set in the main application code, meaning that as you moved lower into the library code, these defines were not required and the codebase “looked normal” with no “per-implementation” hacks to work around certain things. The capy stream concepts and buffers were almost a direct drop-in replacement for the asio buffers. Very little additional code was required and in most cases, it was making sure that the new capy types were compatible with the internal structures used within the production codebase. Using capy::run_async to launch the asynchronous behaviour at various locations in the codebase provided very clear entry points to indicate that asynchronous operations were about to occur. Support for stop_token was already part of our asio codebase which was a custom implementation of P0660 (our implementation pre-dated support in the standard library and the version of gcc that was being used at the time). As such, his custom implementation was replaced with std::stop_token. The majority of this change was replacing the custom namespace with std::. A number of issues were raised during this development period and were resolved very quickly, or alternatives presented (which ultimately made it into the documentation). As a result, the usage of capy within this codebase does not have any drawbacks or missing features. When it came to integrating corosio, the most challenging aspect was re-writing the lambda-style callback-based code with a coroutine based approach. The challenging part was around how to restructure the existing callback code so that lifetime issues were managed correctly. The difference in behaviour between callbacks and coroutines required some thought. One very important lesson when moving from a lambda-style callback chain to coroutines was that simply copying the callback lambda into capy::run_async and having it co_return a capy::task<> was a massive problem, due to IIFE/lifetime/UB traps. This is now very well documented in the capy documentation and I would go as far as to say lambdas (except for very simple usage) should be avoided. Class methods or free functions should be preferred. These denote clearer lifetime semantics and explicit coroutine entry points. When it came to implementing corosio client and server components, the flow control and APIs were all very familiar. The APIs are very similar to asio, so it was possible to make fast progress. The modular design approach taken in the production codebase made it possible to do a side-by-side porting of each asio component to a corosio implementation. At a high level, the following application components were ported over to use corosio: - TCP based clients and servers - UDP based transmitter and receiver. - Application specific timer synchronisation classes. - The core "application" that was used to start the io_context objects had both an asio and corosio implementation. It was of utmost importance that all of the existing tests worked with an asio io_context as well as the corosio io_context (both native and type-erased). Each of the corosio-equivalent classes has identical interfaces so that each of the tests could be called in the same way. A lot of work went into updating the existing tests so that any io_context could be passed and the tests run. Depending on the type of io_context, asio::dispatch or capy::run_async would be used. Care was taken to avoid making behavioural changes to the tests, to ensure that what previously passed would still pass with the corosio version of the test runner. This approach was also taken for all of the core benchmark scenarios, so that a fair comparison could be made between the asio components and corosio components. As a result of extensive test coverage, a number of bugs relating to the corosio io_context were filed and fixed. A number of API changes were required upstream, these were mostly gaps in functionality between corosio and some asio features that were required by the system. For example, supporting the <=> operator for endpoint objects. These changes were added upstream. As a result, all of our use cases and requirements were satisfied. The ports for each component were 100% capy/corosio compatible and did not require any asio interoperability. My overall experience in refactoring this codebase was very positive. I was surprised at how quickly progress was made on porting entire components. I was also very impressed by the speed at which issues were resolved. This is why I do not have any specific gripes about missing features or functionality. This work has been carried out in parallel with the development of capy and corosio. 6. Are the libraries ready for inclusion in Boost? Given the time spent with capy and corosio, I would say that yes, the libraries are ready for inclusion in Boost. The APIs are sufficiently mature and each have an adequate amount of features to be very useful. They provide a familiar approach to what users may already be used to, and expecting, when it comes to asynchronous network programming. Given the well defined design principles, further development and maintenance of these libraries will be possible. 7. If not, what changes would you recommend before acceptance? See point 6. 8. Do the libraries fit well within the existing Boost ecosystem? Yes, having a set of modern coroutine-only C++20 libraries that provides access to executors, buffers, and streams, as well as networking would be a welcome addition. Both capy and corosio would fit well within the existing Boost ecosystem. 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed? I do not have any concerns. Mainly because any issues that I had raised as part of this large-scale refactoring were addressed in one form or another. In most cases, when an API change was made (that was not at the request of this reviewer), it generally caused very little disruption and the change in the production codebase was minimal. This suggests that the designs are mature and well thought out. Any user who is already familiar with asio should see familiar concepts, along with the typical extension points to allow further customisation, if required. Summary: I vote for these libraries to be accepted into Boost.

2 1

[Capy review] Some questions
by Ruben Perez 25 Jun '26

25 Jun '26

Hi all, As you might know, I'm currently using Capy and Corosio in 3 projects: * Boost.Redis [1]: I've implemented a Corosio API matching what we had for Asio. Currently in a PR that will be merged if the libraries are accepted. * A fork of Boost.MySQL [2]. It is functional, but unclear if I will propose it as a new library, or add it to the existing one. * A PostgreSQL library that I'm writing [3]. I'm in general happy. Coroutines make everything much simpler. I don't have this "everything wants to eat me" feeling that writing Asio universal async operations transmits. Benchmarks are also quite promising, well above what we were able to get with Asio. Marcelo did the benchmarks, so I'll leave him to tell the whole story here. I've got some real questions that need answers before emitting a review. 1) What's the status of the interoperability with Asio, and what can we expect? Asio currently has many users who won't migrate their existing code from one day to another. There is a pull request in Capy [4] addressing this. I'd like to know what to expect. Especially, how seamless would the interaction with Corosio (rather than Capy) be? Would the following work? // Code using capy/corosio that creates I/O objects capy::task<> my_capy_task() { corosio::tcp_socket sock {co_await capy::this_coro::executor}; co_await sock.connect(/* whatever */); } // Represents the main application, still using Asio. // At some point, it needs to call out to code using capy/corosio asio::awaitable<void> co_main() { auto exec = capy::wrap_asio_executor(co_await asio::this_coro::executor); co_await capy::asio_spawn(my_capy_task(), compute()); } int main() { asio::io_context ctx; asio::co_spawn(ctx, co_main(), asio::detached); ctx.run(); } In real use cases, it'd be libraries (like Boost.Redis) that may create I/O objects on behalf of the user. 2) What's the rationale for having tls_context::set_hostname but no tls_stream::set_hostname? Say I have a tls_stream I want to re-use for connecting to different hosts (e.g. HTTP redirection, or Redis Sentinel). Different hosts should have different SNIs. But IIUC tls_context is supposed to be set up beforehand and not modified after the stream is created. How do I do this with Corosio? Note that I raised [5] some time ago - this may be a good time to discuss it (I understand everyone has been busy, don't take this as a criticism). 3) Asio has the concept of error dispositions [6]. In a nutshell, these are a generalization of error codes, so custom error types can be used in error code-aware functionality, like when_any. This is useful in code using specialized types. Future candidate Boost.Http uses this in its router [8], and I intended to use it as a way to attach error messages in my database libraries. I discuss my use case in more detail in this issue [9]. Have you considered the feature? 4) Does capy::cond::canceled add anything vs. just using std::errc::operation_canceled? 5) I initially found the when_any semantics confusing. It uses the equivalent to Asio's wait_for_one_success semantics [10]. Asio has also wait_for_one, and it turns out it's the one I tend to need more. Docs [11] propose a workaround - but io_task<std::error_code> doesn't look that good. Is there a chance of adding first-class support for this? What is the rationale behind making wait_for_one_success semantics the default? 6) Can I write types that satisfy ConstBufferSequence or DynamicBuffer without explicitly depending on Capy? This would be useful for low-level protocol libraries that want to take as few dependencies as possible. Setting the concrete const_buffer and mutable_buffer types apart, the usual way of representing "raw bytes" would be span<const unsigned char>/span<std::byte>. For instance, std::as_bytes [12] uses std::byte. If I got the reasoning behind ConstBufferSequence right [13], the purpose is to avoid allocations with vectored I/O. I'd say it's reasonable to allow std::array<std::span<const unsigned char>> to satisfy ConstBufferSequence. Note that I have read The Span Reflex [14]. I agree with the need of ConstBufferSequence. While I personally don't agree with the need of the concrete const_buffer and mutable_buffer types, I understand the rationale of avoiding std::byte. I'm not challenging these types, only asking for better compatibility with std::span. I'll probably get more questions as I explore the parts of the library that I don't have implementation experience with. Congratulations on the work, it's really great. Regards, Ruben. [1] https://github.com/boostorg/redis/pull/417 [2] https://github.com/anarthal/mycosql [3] https://github.com/anarthal/nativepg [4] https://github.com/cppalliance/capy/pull/246 [5] https://github.com/cppalliance/corosio/issues/239 [6] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/Disposi… [7] https://github.com/cppalliance/capy/issues/298 [8] https://github.com/cppalliance/http/blob/1ab0b6fe1763618215d72baaca4859b9a4… [9] https://github.com/cppalliance/capy/issues/298 [10] https://www.boost.org/doc/libs/latest/doc/html/boost_asio/overview/composit… [11] https://master.capy.cpp.al/capy/4.coroutines/4f.composition.html#_errors_do… [12] https://en.cppreference.com/cpp/container/span/as_bytes [13] https://master.capy.cpp.al/capy/5.buffers/5a.overview.html#_the_concept_dri… [14] https://www.vinniefalco.com/p/the-span-reflex-when-concrete-thinking

7 36

[Capy review] On integrating nonblocking C libraries with corosio
by Ruben Perez 24 Jun '26

24 Jun '26

Corosio's tcp_socket::wait docs state: "Wait for the socket to become ready in a given direction. [...] useful for integrating with C libraries that own the I/O on a nonblocking fd and only need readiness notification (e.g. libpq async, libssh)." I know that Klemens wrote a libssh wrapper [1] using this. Since the docs mention libpq, I thought I would give it a try. libssh allows setting a user-supplied socket using ssh_socket_set_fd [2]. This works great with tcp_socket::wait: you create your corosio socket and call ssh_socket_set_fd(sock.native_handle()). libpq gives you a read-only socket handle with PQsocket [3]. This means that the pattern above does not work here. With Asio, I can write this: asio::awaitable<void> co_main() { PGconn* conn = PQconnectStart( "host=127.0.0.1 dbname=postgres user=postgres password=secret sslmode=disable"); if (!conn) { std::cerr << "Failed PQconnectStart\n"; exit(1); } struct deleter { void operator()(asio::ip::tcp::socket* d) const { boost::system::error_code ec; d->release(ec); } }; asio::ip::tcp::socket descr{co_await asio::this_coro::executor}; bool finished = false; while (!finished) { switch (PQconnectPoll(conn)) { case PGRES_POLLING_READING: { std::cout << "wait_read\n"; descr.assign(asio::ip::tcp::v4(), PQsocket(conn)); std::unique_ptr<asio::ip::tcp::socket, deleter> guard{&descr}; co_await descr.async_wait(asio::ip::tcp::socket::wait_read); break; } case PGRES_POLLING_WRITING: { std::cout << "wait_write\n"; descr.assign(asio::ip::tcp::v4(), PQsocket(conn)); std::unique_ptr<asio::ip::tcp::socket, deleter> guard{&descr}; co_await descr.async_wait(asio::ip::tcp::socket::wait_write); break; } case PGRES_POLLING_FAILED: std::cerr << "Poll failed\n"; finished = true; break; case PGRES_POLLING_OK: default: finished = true; break; } } PQfinish(conn); co_return; } Which is a bit awful, but does work in Linux, and I think _should_ happen to work on Windows, too. Points to note here: * PQsocket returns a _non owning_ socket handle. Asio (and corosio) sockets are owning. We need to take extra steps to avoid the socket being closed. * PQsocket might return a different socket at each call. This happens when trying several servers until one works. * PQsocket returns an int even in Windows, where SOCKET is unsigned. If the returned socket is valid, the value on Windows is the actual SOCKET, cast to an int [4]. * asio::tcp::socket::assign takes a native_handle_type, which is an int on POSIX, and a class constructible from SOCKET on Windows [5]. The problem I've found with Corosio is that (by design) there is no tcp_socket::assign (because this takes a native type), so this pattern doesn't work. Considering that the docs mention libpq explicitly, what am I missing here? Note that libmariadb [6] and libmosquitto [7] follow libpq's pattern. Thanks, Ruben. [1] https://github.com/klemens-morgenstern/corosh [2] https://api.libssh.org/stable/group__libssh__socket.html [3] https://www.postgresql.org/docs/current/libpq-status.html [4] https://github.com/postgres/postgres/blob/56b2792cf84fc78f9109b0ae122174e70… [5] https://github.com/boostorg/asio/blob/cba4d9791d77264814eccb53324d5d3766946… [6] https://mariadb.com/docs/server/reference/product-development/mariadb-inter… [7] https://mosquitto.org/api2/files/mosquitto-h.html#mosquitto_socket

2 1

CVE-2026-11460 - security flaw in serialization
by Chris Frey 24 Jun '26

24 Jun '26

I haven't seen mention of this on this list yet, so just passing it along. Vulnerability page: https://vuldb.com/cve/CVE-2026-11460 More details: https://gist.github.com/TrebledJ/b7c872f869b5ed7cbd936f71f16c7d75 - Chris

8 17

[capy] the Buffer nomenclature
by Andrzej Krzemienski 22 Jun '26

22 Jun '26

Hi All, The Capy+Corosio review has not yet started but, as Jeff pointed out, two weeks will likely not be enough, so I might as well post right now. Disclosure: I am affiliated with the C++ Alliance, and have been contributing to Capy. This post is to share a reflection on the naming around buffers present in Capy. Capy inherited the names from ASIO, and ASIO was strongly influenced by the naming in the operating systems. So this observation applies not only to Capy. Philosophically, a buffer is a solution to the problem of producer producing and consumer consuming data at different paces. This is done via buffering and for this we use a "buffer", that is, some memory, not necessarily contiguous. We have the following elements. 1. A contiguous region of memory whose lifetime is managed by the programmer. 2. We have a view-like handle providing access to this region of memory. 3. When a read or write operation needs access to space for buffering, it is given a "structure" of handles that together give access to all of the memory available for buffering. 4. A "dynamic" storage, which can be reallocated if needed, where some storage is devoted to a buffer for reading and another for a buffer for writing. In Capy, #1 doesn't have a name, #2 is called const_buffer/mutable_buffer, and #3 is called ConstBufferSequence, MutableBufferSequence, Where a "buffer sequence" is either a buffer or a range of buffers. #4 is called DynamicBuffer. This naming has been very confusing to me, and the library design only started to make sense for me, when I mentally used a different naming: #1 doesn't need a name #2 read_region/write_region #3 ReadBufferView/WriteBufferView #4 DynamicStorage The read/write vs const/mutable is secondary, but the regions and buffer views make a lot of things clearer: Algorithm `write` needs a buffer: somewhere to write bytes to: it can be a contiguous memory region or a sequence thereof. The buffer is all the memory the operation has at its disposal. We avoid this recursive notion that a buffer is a buffer sequence. Names read more naturally: template <ReadStream S, ReadBufferView B> auto read(S& stream, B buffer) { size_t size = capy::buffer_size(buffer); // ... } template <ReadStream S, DynamicStorageParam Store> auto read(S& stream, Store&& storage) { ReadBufferView buffer = storage.prepare(1024); // ... } If the goal of not confusing current ASIO users is more important than not confusing new users, then the current names had better stay, but the above description in the documentation might help new users to grasp the concepts. If, on the other hand, the library is prioritizing new users, maybe we could consider changing the nomenclature. Regards, &rzej;

3 2

Boost.Graph Documentation Got a Facelift: Ship it Or Not ?
by Arnaud Becheler 20 Jun '26

20 Jun '26

Dear Boostlings, Graphlings, We have taken a first step in modernizing the Boost.Graph documentation with a preview available here: https://491.graph.prtest3.cppalliance.org/graph/index.html . These first steps aim at solving low-hanging fruits and answering frequent complaints from users collected during the 2022 User Survey ( https://www.reddit.com/r/cpp/comments/vyt4t5/boostgraph_user_survey/ ) and BGL workshop 2026 ( https://github.com/boostorg/graph/discussions/466 ) - documentation hard to explore (no table of content, no search bar) - examples use old C++ and several don't even compile - outdated visual design We have been investing into several dimensions: - migrating the old pure html pages to asciidoc + antora - modern examples for each algorithm are compiled and run in CI, with output integrated in the documentation - higher scanability for algorithm complexity + where defined - a better landing for users not familiar with property maps The PR currently sits unmerged as we are trying to assess its viability. Important: - this is NOT the final vision, this is meant as a first important step. - the current scope is NOT a full rewrite/reorganization of each algorithm page (future work). - the current scope is a modernization of the documentation infrastructure. - we are just worried we may have made and missed important mistakes that should prevent the merge, so Jeremy Murphy (principal BGL maintainer) and I decided to poll around for general review and feeling. Question to the community: 1. Is the new documentation preview ( https://491.graph.prtest3.cppalliance.org/graph/index.html ) going in the right direction? 2. Is it better than the old documentation ( https://www.boost.org/doc/libs/1\_91\_0/libs/graph/doc/ )? 3. Would you want to see it merged in its current state or did you identify important mistakes we should absolutely fix before merge? Any general complaints not directly related to this PR scope is welcome and will be integrated in future work :) Thank you, Arno

4 10

100MB of Node.js modules shipped in the Boost release tarball
by Jonathan Wakely 19 Jun '26

19 Jun '26

There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball. Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems. Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball? I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.

5 12

[Patch] modernize the codebase of Boost.Format which replace the old typdef with using alias
by frex_vk9 15 Jun '26

15 Jun '26

Hello. I saw that Boost require C++11 so i modernize the codebase of Boost.Format i replaced the old typedef with using alias for upgrade the lisibility for codebase in the future. and the test with b2 passed. Read the .patch file for review my commit. Regards. frex_vk9(a)proton.me

2 1

Vcpkg Binary Caching on GitHub Finally Made Easy
by Richard 14 Jun '26

14 Jun '26

Hi Boosters, <https://github.com/LegalizeAdulthood/vcpkg-github-cache> For a long time I've struggled with vcpkg binary caching on my github CI jobs. There's a variety of critical information buried deep across various documentation pages that all interact when you attempt to use binary caching on a github repository with public github runners and CI workflows. This weekend I finally got it all figured out and debugged for my public repositories and realized that the steps needed to make everything work are non-obvious and intricate. This is the perfect thing for packaging up as a github workflow action for reuse across repositories. This project consists of two actions: - one that does all the setup - one that analyzes your build log This gives you details on how your build interacted with vcpkg binary caching to report problems. Usually the build summary is all you need to understand the cache: cold seed, warm hit, partial hit, etc. Should you need to dig in deeper to debug a weird situation there are two knobs -- debug and trace -- that can give you enough detail on everything that happened so you can sort out problems without having to manually add logging to your workflow. It may still be necessary to manually adjust the permissions on individual packages that are shared across repositories on your account. Unfortunately there's no way to manipulate the permissions programmatically. The analyze action smooths this out by giving you a table of packages that had permission issues, with links to each package's permission page on github. From there you can quickly adjust permissions as needed without having to hunt through a long list of packages on your account. -- Richard -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0