Re: Capy Review

On Thu, Jun 25, 2026 at 11:08 AM Andrzej Krzemienski <[email protected]>
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
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/S6BET7RAODGLMVH7Q4DXYE7YQY4EXEUO/