Capy and Corosio review

Marcelo Zimbres Silva via Boost <[email protected]> Fri, 3 Jul 2026 20:43:47 +0200
Newsgroups gmane.comp.lib.boost.devel
Message-ID <CAPGXEnGOO7HB9H6OVJXJgSfbOmo917b+wv748JGAHG+oVcQiGA@mail.gmail.com>
Hi, this is my Capy/Corosio review.

> 1. What is your evaluation of the usefulness of the libraries?

>From Corosio point of view I think there is no need to elaborate. A
networking library is immensely useful.

The Capy library provides ground for sans-io protocol libraries, which
is fundamental for testability. I am not sure whether it is the best
option from the performance point of view (as discussed in another
thread) but that is only possible to evaluate once more libraries are
built on top of it. Boost is the correct place for such experiments
though.

> 2. What is your evaluation of the design?

It has addressed many of the problems we encounter when developing
libs on top of Asio

  - capy::any_stream: In Asio it is burdensome to write a connection
type that works with both plain and secure connections i.e. pass
either stream or stream.next_layer(). Capy any_stream simplifies this.

  - Type erasure. In Capy I don't have to think about type erasure
whereas in Asio I need any_io_executor and any_completion_handler.

  - In Boost.Redis we offer basic_connection<Executor> and  connection
(ype-erased), whereas the Capy-based Boost.Redis has only one
connection type i.e. co_connection. That is a big win for users.

  - By being a coroutine from the ground up it does not need the
completion token model from Asio and achieves much faster compilation
times. This is again a big win.

  - More async primitives e.g. capy::async_event. I have to
investigate more but this might be related to the performance
improvements I have observed in my benchmark report.

> 3. What is your evaluation of the implementation?

I haven't looked at the implementation but it seems reliable. As Ruben
already pointed out, the Boost.Redis port to Corosio passes tests and
has impressive performance. No concerns here.

> 4. What is your evaluation of the documentation?

It is very good although I think it often contains too many words.

> 5. Have you used either or both libraries? What was your experience?

I wrote a performance benchmark using corosio

https://github.com/mzimbres/redis-cli-comp/blob/main/apps/boost-redis/app_boost_redis_corosio.cpp

and was happy I did not have to type async_ prefixes anymore :) There
is no friction for users with Asio experience.

> 6. Are the libraries ready for inclusion in Boost?

Yes. It is the correct time to let it mature in Boost and gain more feedback.

> 8. Do the libraries fit well within the existing Boost ecosystem?

Yes, but it is important to notice that Corosio competes with Asio and
increases the ecosystem fragmentation.  This is not a Capy/Corosio
fault and there is precedent for competing libraries in Boost, but it
really hurts the overall C++ software quality, for example, when your
http client uses one net lib, the database driver another and so on.
Perhaps soon there will be a senders and receiver based net lib.
Libraries aren't likely to support all net variations natively and
interop will be more likely.

> 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed?

I vote ACCEPT.

Thanks,
Marcelo
_______________________________________________
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/5PWZGNTYWYZWCHAESQVWPHBI6W67Y67I/