On Thu, Jun 25, 2026 at 11:08 AM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
About this "Asio got many things right" statement. It looks like it presupposes that the community here universally agrees that design decisions in ASIO are right.
That's a fair point and one worth exploring. Boost.Asio gets a lot of things right because of convergent evolution. Multiple operating systems and libraries independently converged on the same shape for I/O operations. P4100R1 Section 4.8 shows some examples: *Coroutine-Native I/O for C++29 (The Network Endeavor)* https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4100r1.pdf
...the design of ASIO is known to have been criticised, for instance in wg21.link/p2464r0.
Great point and I am so glad you brought this up: *Ruminations on networking and executors* https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2464r0.html This paper represents the climax of a series of papers and design decisions which, analyzed locally, made sense. Yet if you trace the evolution of those design choices you discover what I call the Rationale Loss mechanism: when new papers are written by new authors, and the tacit knowledge of the original authors whose work the new papers are based on does not transfer, the rationale for the early decisions is not carried and the new designs drift. To be specific, the Asio executor invokes continuations. That is, the resumption of a suspended function when the asynchronous operation it initiated completes. Over time, this rationale was lost, and new papers converged on a different framing: that the executor invoked work, the invocation could fail, and the invoker would receive the result of the submitted work. The former is called continuation-framing, and the latter is called work-framing. Asio's executor description used the continuation-framing. P2464R0 describes a work-framing executor. P2464 is correct under work-framing but incorrect under continuation-framing. This is analyzed in my 6-paper networking retrospective. The paper in the series *Coroutine Executors and P2464R0* https://isocpp.org/files/papers/P4096R1.pdf
Coroutines in C++ bring a new perspective, new capabilities perhaps, and new expectations.
Yes :) and after developing Capy and Corosio my first instinct was to create quite a few papers analyzing the history of networking in C++, and the decisions that went into it. I am told I wrote too many papers. I say, that other people are not writing enough. But I digress.
These may be an additional reason to question the design in ASIO. Given that Capy/Corosio authors decided to inherit the design from ASIO (this is a design decision), it is on them to also, at least to some extent, defend ASIO's decisions.
Kohlhoff's continuation-framed executors were critiqued as insufficient under the work-framing, and the entire Networking TS was effectively rejected because of this. And that was a mistake, as I analyze in my papers. Now here is where it gets somewhat humorous. WG21 rejecting Networking TS didn't change the underlying technical requirements nor the rationale. At the last minute, the committee rediscovered that continuation-framed schedulers were in fact necessary. At the 11th-hour at the Croydon meeting they invented "infallible schedulers." In other words they rediscovered Asio's continuation-framed executors. This is described in my upcoming paper: * P3552: The Return of Networking TS Executors* https://isocpp.org/files/papers/P4286R0.pdf Thanks