[Capy/Corosio review]

29 Jun 2026

      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.

James Earnshaw

Steve Gerbino

tags

participants (2)