P2444 The Asio asynchronous model

[wg21bot]

P2444R0 The Asio asynchronous model (Christopher Kohlhoff)

[brycelelbach]

2021-09-20 Joint Library Evolution and Concurrency Telecon

P2444R0: Asio Asynchronous Model

P2300R1: std::execution

P2463R0: Asio Asynchronous Model Slides

2021-09-20 Joint Library Evolution and Concurrency Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Chris Kohlhoff

Minute Taker: Dietmar Kuhl

Start: 2021-09-20 14:15 Pacific

Is this proposal an alternative to senders/receivers?

What would be wrong with having both this Asio model and senders/receivers in the Standard Library?

How does this model support compute and structured concurrency? What about bulk execution?

POLL: Knowing what we know today, we should continue considering shipping the Networking TS in C++23, as is.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	6	8	3	3

Attendance: 36

Author Position: SF

Outcome: No consensus.

POLL: Knowing what we know today, we should continue considering shipping P2300 senders/receivers in C++23.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	6	5	5	4

Attendance: 36

Outcome: No consensus.

End: 15:40

Summary

A detailed presentation was given on Asio's asynchronous model, which the Networking TS is based on.

Afterwards, we briefly discussed whether the Networking TS needs to be linked to senders/receivers. We also started discussing whether we wanted to ship the Networking TS in C++23; more discussion will be needed before we reach a conclusion.

Outcome

The review of P2300 std::execution and discussions of executors, senders, receivers, networking, and the Networking TS will resume at future Library Evolution and Concurrency telecons.

[brycelelbach]

2021-09-28 Joint Library Evolution and Concurrency Telecon

P2444R0: Asio Asynchronous Model

P2463R0: Asio Asynchronous Model Slides

P2300R1: std::execution

2021-09-28 Joint Library Evolution and Concurrency Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Chris Kohlhoff

Minute Taker: Ben Craig

Start: 2021-09-28 7:12 Pacific

Set aside senders/recievers and Net TS interoperability for now.

POLL: We must have a single async model for the C++ Standard Library.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	9	10	11	5

Attendance: 49

Outcome: No consensus.

POLL: Knowing what we know today, we should continue considering shipping the Networking TS in C++23.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
9	9	8	8	3

Attendance: 48

Outcome: No consensus.

POLL: Knowing what we know today, we should continue considering shipping P2300 std::execution in C++23.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	9	6	6	6

Attendance: 47

Outcome: No consensus.

End: 8:40

Summary

We finished the presentation of Asio's asynchronous model at today's meeting, specifically the section covering completion tokens.

We then dove into a discussion of how to proceed with the Networking TS and senders/receivers. We considered decoupling the two, and what implications that would have on future planning and interoperability. If we shipped the Networking TS in C++23, would we be able to write wrappers that allowed it to interoperate with senders/receivers later? If we ship senders/receivers without properties, does anything preclude us from adding them later?

We also briefly discussed the ABI stability of the Networking TS, and how ABI stability needs could be problematic if we added TLS facilities to the Networking TS.

We still have not reached a conclusion of our discussions on these topics.

Outcome

The review of P2300 std::execution and discussions of executors, senders, receivers, networking, and the Networking TS will resume at future Library Evolution and Concurrency telecons.

[brycelelbach]

2021-10 Library Evolution / Concurrency Polls on Networking and Executors

Consensus and outcomes determined by @ben-craig and @FabioFracassi.

Poll 1: The Networking TS/Asio async model (P2444) is a good basis for most asynchronous use cases, including networking, parallelism, and GPUs.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	10	6	14	18

Outcome: Weak consensus against.

What this doesn't mean: It doesn't mean that the NetTS async model isn't a good fit for networking. There were many comments to the contrary.

What this means: If the authors continue to pursue a design similar to the current NetTS, they would have an easier time getting consensus by focusing on the networking side of things, rather than proposing the design for general asynchrony.

Poll 2: The sender/receiver model (P2300) is a good basis for most asynchronous use cases, including networking, parallelism, and GPUs.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
24	16	3	6	3

Outcome: Consensus in favor.

What this doesn't mean: It doesn't mean that S&R is going into C++23 (though it might). It doesn't mean that P2300 as it stands today will be sent forward to LWG. It doesn't prevent us from adding new asynchronous models in the future.

What this means: Work will continue in LEWG on refining P2300, and LEWG will keep the various asynchronous use cases in mind while working on P2300.

Poll 3: Stop pursuing the Networking TS/Asio design as the C++ Standard Library's answer for networking.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
13	13	8	6	10

Outcome: No consensus

What this doesn't mean: The NetTS is not "dead".

What this means: WG21 will still work on networking in this general form, but the authors need to do a lot in order to build up consensus to get something like the TS merged into the standard. The bulk of this work should be done in SG4. Many of the people in favor of stopping work on the TS would like networking to be built on top of Senders and Receivers. Others were opposed to the lack of security through Transport Layer Security (TLS). It is highly unlikely that design changes to the networking TS can be made fast enough, and consensus gained fast enough, for networking to make C++23.

Poll 4: Networking in the C++ Standard Library should be based on the sender/receiver model (P2300).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
17	11	10	4	6

Outcome: Weak consensus in favor.

What this doesn't mean: Work on networking using other models will still be reviewed and considered on its own merits. WG21 doesn't pause work on a concrete paper based off of the wish for another paper. Note that there are a high number of neutrals on this vote. Many of the neutrals (and some of the abstentions) would like to see a paper before picking a side here.

What this means: In the short term, this poll result doesn't mean much. We don't have a paper in hand that proposes networking based on the P2300 model. For paper authors though, this poll is encouragement to do work in the area of networking based on senders and receivers, or to be prepared with compelling new information on why networking should use a different model.

Poll 5: It is acceptable to ship socket-based networking in the C++ Standard Library that does not support secure sockets (TLS/DTLS).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
9	13	5	6	13

Outcome: No consensus.

What this means: A networking library that does not support secure sockets will face significant headwinds getting through the standardization process.

What this doesn't mean: This doesn't make a statement on whether insecure networking should be included, the defaults of secure vs. insecure, or how things like ABI should managed.

Guidance for the Networking Study Group

Before bringing networking papers back to LEWG, two major areas need to be thoroughly addressed: Security, and the Senders and Receivers async model.

Those voting in favor of Poll 5 argued that the insecure parts are the building blocks for the secure parts, and that ABI is major concern that will plague TLS support. Those voting against Poll 5 argued that secure sockets are needed for communicating with many sites on the internet, and that shipping without secure sockets would be irresponsible. A networking proposal needs to address these concerns before coming to LEWG.

As for networking in combination with Senders and Receivers, I will show this older poll from the 2021-09-28 telecon:

POLL: We believe we need one grand unified model for asynchronous execution in the C++ Standard Library, that covers structured concurrency, event based programming, active patterns, etc.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	9	5	5	1

Outcome: No consensus (leaning in favor).

The combination of this "grand unified model" poll and Poll 4 heavily encourages the networking study group to produce a paper based on Senders and Receivers. There is room to produce a non-S&R paper, but such a paper would need to provide compelling new information in order to convince the "grand unified model" contingent that S&R can't get the job done suitably.