June 2026 - Boost - lists.boost.org

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