On 06/07/2026 23:58, Vinnie Falco via Boost wrote:
On Mon, Jul 6, 2026 at 2:53 PM Andrzej Krzemienski <akrzemi1@gmail.com> > wrote: > [...]
I did not mean C++26 executors as the alternative. I was thinking more >> in the vein of https://github.com/ClickHouse/silk. >> > > Stackful coroutines ("fiber" in silk parlance) are wonderful. And Nat > Goodspeed should not have waited over twelve years to get them in the > standard. They do not replace stackless coroutines, nor do they compete > with them. They are a legitimate tool which solves the same problem with a > different set of tradeoffs. > > C++ needs them, just as much as it needs frame-opaque stackless coroutines. > And I would argue the language needs frame visible coroutines as well. This > is not contested and I have written a paper saying so: > > *Benefits of Frame-Visible Coroutines for Senders* > https://isocpp.org/files/papers/P4166R0.pdf > However, they are unsuited to a large class of I/O problems, networking in > particular. > > Jamie, do you want to build your system on fibers, or stackless coroutines? > I wish I could use a thread-per-connection, on a system with latency-free context switching and unlimited memory :-p
Seriously though, while I know some people are doing a great job of advancing the state of the art for stackful coroutines (and therefore fibers) they're not as good a fit for the kind of scalability we need. Stackless coroutines are that building block. Pre std::coroutine and Capy we made use of Asio stackless coroutines for the parts of the code that really needed it: https://www.boost.org/doc/libs/latest/doc/html/boost_asio/overview/compositi... Jamie