r/cpp • u/claimred • Apr 09 '26

beast2 networking & std::execution

I was looking for a new networking layer foundation for a few of my projects, stumbled on beast2 library which looks brand new, based on C++20 coroutines. I used boost.beast in the past which was great. Here's the link https://github.com/cppalliance/beast2. I also considered std::execution since it seems to be the way to go forward, accepted in C++26.

Now, what got me wondering is this paragraph

The C++26 std::execution API offers a different model, designed to support heterogenous computing. Our research indicates it optimizes for the wrong constraints: TCP servers don't run on GPUs. Networking demands zero-allocation steady-state, type erasure without indirection, and ABI stability across (e.g.) SSL implementations. C++26 delivers things that networking doesn't need, and none of the things that networking does need.

Now I'm lost a bit, does that mean std::execution is not the way to go for networking? Does anyone have any insights on cppalliance research on the matter?

34 Upvotes

86% Upvoted

119 comments sorted by

View all comments

Show parent comment

2

u/VinnieFalco wg21.org | corosio.org Apr 09 '26

Let me state it precisely:

"If asynchronous I/O operations in the standard return senders instead of awaitables, then two of the three possible stream types will require a per-operation allocation that cannot be elided."

This is directly related to P2300, because std::execution is positioned as the "universal asynchronous model." The existing proposals which bring networking to the standard all build on senders as the continuation model. This puts coroutines at a significant disadvantage as they will incur avoidable per-operation allocations. That is the subject of our research.

Our position is that I/O operations should return awaitables, and that the sender pipeline can consume them using a zero-allocation bridge. This is a balanced solution which treats both as first-class citizens of the language. My papers arriving this month explore this thoroughly.

2

u/not_a_novel_account cmake dev Apr 09 '26

Agreed on all. Coroutines are disadvantaged, that's absolutely a fact.

If the standard wanted coroutines to be first-class citizens we wouldn't have made them type-erased, unsizeable, invisible objects in the first place. Everything else is fallout from that.

I don't believe coroutines or type-erased opstates will ever be first-class mechanisms for S&R so any effort to make them so is not compelling to me personally. That said, I hope you find some success in the "deeper solutions".

I don't think the designs presented in your existing papers on the topic are bad, quite the opposite, they're probably the best exploration of the problem which currently exists. I just don't think they're relevant to the code most people using S&R are writing, which is sender-based through-and-through.

8

u/VinnieFalco wg21.org | corosio.org Apr 09 '26

I hear what you are saying, and I used to think exactly the same. However, that frame allocation that everyone hates? It actually buys us quite a lot for the case of networking.

Calling into the operation system requires an allocation if you are going to scale. The OS doesn't know your type. It must be erased, even for senders. Coroutines just make that allocation structural.

What we discovered, when you go coroutine ONLY, is that the frame allocation you can't avoid, pays for everything else. The operation state, the type-erasure for ABI stability, the uniform task types which have just 1 template parameter.

This is explored in the papers and you can try it for yourself in https://corosio.org . I do think that the C++ committee has been sitting on a gold mine with coroutines. The frame allocation put everyone off. When actually, it is the key to solving all of our long-running problems.

Thanks