P2300 R10 `std::execution`

[wg21bot]

P2300R0 std::execution (Michał Dominiak, Lewis Baker, Lee Howes, Michael Garland, Eric Niebler, Bryce Adelstein Lelbach)

[brycelelbach]

2021-07-06 Joint Library Evolution and Concurrency Telecon

P2300R1: std::execution

2021-07-06 Joint Library Evolution and Concurrency Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Michael Garland

Minute Taker: Ben Craig

Start: 2021-07-06 10:08 Pacific

This week, the authors will present the proposal and we'll identify what questions we have and what areas we need to explore. In subsequent meetings, we'll dive into questions and feedback in greater detail.

The UK delegation feedback will be reviewed at a future meeting.

Start User Facing Presentation: 2021-07-06 10:11 Pacific

End User Facing Presentation: 2021-07-06 10:41 Pacific

Start Implementer Interface Presentation: 2021-07-06 10:54 Pacific

End Implementer Interface Presentation: 2021-07-06 11:05 Pacific

The motivation for both maybe eager and strictly lazy models needs to be clearer and strengthened.

Add discussion of the role, interactions, and compatibility of coroutines in senders/receivers.

Senders should probably be awaitable.

Sender adaptor piping vs coroutines.

Is sender adaptor piping fundamental to the proposal? It doesn't seem like it is.

What does shape mean in the context of bulk? What are the implications for chunking? Is chunking allowed? Clarify this.

Should bulk take an execution policy?

Add more examples of multi-shot vs single-shot.

Consider introducing a maybe_force that possibly starts, but is not required to.

Ensure that set_value, set_error, and set_done use tag_invoke.

Should we decouple the Networking TS from executors/senders/receivers?

Library Evolution needs to decide whether we are going to standardize the existing practice of Boost.Asio via the Networking TS.

Topics to Polls:

• Distinct maybe eager and strictly lazy versions of sender algorithms.
• Shipping the Networking TS.

End: 11:49

Summary

Library Evolution and Concurrency met for a joint review of P2300 std::execution. This was the first time that the proposal was reviewed, so this session was primarily an overview and tour through the proposal. After the author's presentation, we began discussing open questions and feedback.

One of the major areas of uncertainty was the existence of two variants of sender adaptors - maybe eager and strictly lazy. Some questioned the need for the maybe eager variants, given that we have facilities like ensure_started. The authors will need to include stronger motivation of this in future revisions, and we will definitely need to make a decision on whether we want to go this route. The alternative is to just have strictly lazy algorithms and a way to eagerize explicitly, e.g. ensure_started.

A number of questions were raised about how coroutines fit into the senders/receivers model presented by P2300. Some comparisons and contrasts where made between P2300's sender adaptor piping syntax and coroutines (in particular, coroutines as used in the Networking TS). The authors explained that while coroutines are powerful, they can't necessarily express all aspects of the sender/receiver model, such as the error and cancellation channels, and may have unnecessary overhead in some cases.

We discussed the removal of properties, which P2300 proposes. It was pointed out that there was not prior guidance to make this change, so this is a design change from P0443. The authors indicated that they believe that properties could be added to P2300 after it ships.

We also considered the interactions and relationship between P2300 and the Networking TS. Some asserted that it was unclear if P2300 could support the Networking TS or async I/O. The authors explained how P2300 could be used for async I/O and pointed to libunifex for implementation experience. They indicated that I/O schedulers could be written with senders as they are in P2300, although we may need additional scheduler concepts in the future.

Finally, we talked about whether the Networking TS and executors/senders/receivers should remain coupled. Some said out that we have been trying to develop a "grand unified" async model for years, and perhaps that is a mistake. Others pointed out that it may be a mistake to try and retrofit the Networking TS, which is based on established practice from Boost.Asio, with a new model. We could choose to ship the Networking TS with its current model and also develop and ship a new model (e.g. executors/senders/receivers). We could also choose to not ship the Networking TS, and ship a networking library built from the ground up around executors/senders/receivers.

The Networking TS has been in flight for a long time now. The C++ committee needs to make a decision about whether we are going to ship the Networking TS with its current model or whether we want a different networking story. We also need to decide the degree to which we want networking and executors/senders/receivers to be coupled.

The UK delegation is putting together a more complete set of feedback from their members, which will hopefully be ready for presentation at the next meeting, or the subsequent one.

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-07-12 Joint Library Evolution and Concurrency Telecon

P2300R1: std::execution

2021-07-12 Joint Library Evolution and Concurrency Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Michal Dominiak

Minute Taker: Inbal Levi

Start: 2021-07-12 14:08 Pacific

BSI position slides should be published as a P paper.

Surfacing different kinds of cancellation:

• Terminal
• Partial - set_done(how much succeeded)
• Total

There's an ask to be able to express partial results and to expose what types of cancellation a sender supports.

Who is responsible for handling exceptions?

Should set_value always be noexcept?

transfer algorithms need to be exception firewalls.

Expected errors vs unexpected errors.

Different completion schedulers for set_value, set_error, and set_done.

Do we need a way to ask that a scheduler run completion on a particular context?

Tail calls and sender authoring.

3 sender channels vs 1 sender channel.

End: 15:31 Pacific

Summary

We continued our review of P2300 with a presentation from members of the UK delegation explaining their feedback.

First, we discussed cancellation. It was suggested that we need to be able to surface and distinguish between different types of cancellation, such as terminal, partial, and total cancellation. Some expressed a need to support sending partial results or partial success, and there was a question of whether this is possible with the current proposal.

We also considered whether the three channels that senders/receivers support are sufficient and necessary. Some suggested that they could be condensed to a single channel, while others suggested that the three channels may be insufficient.

Finally, we discussed the matter of what context receiver functions will complete on, and how this may be complicated when some signals are mapped to other signals.

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-07-26 Joint Library Evolution and Concurrency Telecon

P2300R1: std::execution

2021-07-26 Joint Library Evolution and Concurrency Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Michal Dominiak

Minute Taker: Ben Craig & Gasper Azman

Start: 2021-07-26 07:18 Pacific

Questions we should feel comfortable answering before we poll on P2300:

• Is P2300 an improvement upon or a regression from P0443?
• Is the cancellation model in P2300 acceptable?
• Is the error handling model in P2300 acceptable?
• Is a generic property system a pre-requisite to ship executors?
• Should the paper include facilities for starting detached work? Should one-way execution be supported?
• Do we need to support both a strictly lazy and maybe eager model? Is a strictly lazy model with an explicit way to eagerize acceptable?
• Do we believe we can build ... on top of what is in P2300?
  • Parallel algorithms, including future extensions like asynchronous algorithms?
  • A future Standard C++ networking library?
  • A future Standard C++ asynchronous I/O library?
• Do we understand the potential interactions of senders/receivers and ...
  • Coroutines?
  • The Networking TS?

Some are unclear how they would implement sender algorithms.

Some are concerned about the context in which a receiver signal will be called.

"If I'm writing a scheduler, what else will I have to implement at the same time?" Presumably a sender, an operation state, an execution context, and some CPOs.

What is set_error actually for? Expected errors? Unexpected errors?

How do you express partial success or errors with a side effect? Partial success calling set_value is unpalatable to some.

Should the default definition of bulk be parallel or serial?

Chris K should present the Networking TS compositional model to Library Evolution.

Coroutines vs senders/receivers as the base language for expressing parallelism.

Demonstrate that senders are awaitable in P2300.

Add example of simple scheduler to P2300.

End: 8:37

Summary

We continued today discussing the feedback from the UK delegation on P2300.

The chair presented some questions that he wants participants to feel comfortable answering before we poll:

• Is P2300 an improvement upon or a regression from P0443?
• Is the cancellation model in P2300 acceptable?
• Is the error handling model in P2300 acceptable?
• Is a generic property system a pre-requisite to ship executors?
• Should the paper include facilities for starting detached work? Should one-way execution be supported?
• Do we need to support both a strictly lazy and maybe eager model? Is a strictly lazy model with an explicit way to eagerize acceptable?
• Do we believe we can build ... on top of what is in P2300?
  • Parallel algorithms, including future extensions like asynchronous algorithms?
  • A future Standard C++ networking library?
  • A future Standard C++ asynchronous I/O library?
• Do we understand the potential interactions of senders/receivers and ...
  • Coroutines?
  • The Networking TS?

First, we focused again on how you can express partial successes with senders/receivers. It is unclear to some whether senders/receivers can express partial success. Others believe that it is trivial to do so via the arguments you pass to set_value. However, some desired a generic way to deal with partial success, although others questioned what the use case for that would be.

We also discussed the semantics of the default definition of bulk, which is serial. This was surprising to some. There was some question about what set of CPOs need to be customized by a scheduler and what things need to be defined when writing your own scheduler.

Once again, questions about the interoperability between senders and coroutines was mentioned. The authors explained that senders are awaitable, and that future revisions of P2300 will discuss this.

There was a claim that the Networking TS's async model was a viable alternative to senders/receivers and should be considered as well. The proponents of this claim agreed to produce a proposal and presentation explaining their thesis.

It became clear during our discussion that the Networking TS has an async model distinct from senders/receivers. This was true with P0443 and P2300, so this is not a regression in the new proposal. If we truly want a "grand unified async model", either we must adopt the Networking TS's async model, or modify the Networking TS. Some questioned the utility and need for a "grand unified async model", and suggested that we should perhaps decouple the Networking TS from senders/receivers.

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.

At the next meeting, we will discuss whether properties are essential and whether we need to have both strictly lazy and maybe eager forms of algorithms.

[wg21bot]

P2300R1 std::execution (Michał Dominiak, Lewis Baker, Lee Howes, Kirk Shoop, Michael Garland, Eric Niebler, Bryce Adelstein Lelbach)

[brycelelbach]

2021-08-03 Joint Library Evolution and Concurrency Telecon

P2300R1: std::execution

2021-08-03 Joint Library Evolution and Concurrency Telecon Minutes

Chair: Bryce Adelstein Lelbach & Ben Craig

Champion: Corentin Jabot

Minute Taker: Ben Craig & Inbal Levi

Start: 2021-08-03 14:19 Pacific

Topics for today:

• Is there a capability gap between P0443 and P2300? Is it acceptable?
• Is a generic properties system a prerequisite for executors?
• Do we need both a "strictly lazy" and "maybe eager" model?

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

Attendance: 29

Outcome: No consensus (leaning in favor).

N: I'd prefer one grand unified model, but it isn't a dealbreaker if we can't do it

SA: I think we are making too many compromises for the simple case in favor of the very complicated heterogeneous case

POLL: In P2300, in addition to ways to query the properties of schedulers, we think we need ways to transform schedulers into other schedulers, like P0443 did with prefer and require.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	1	14	6	2

Attendance: 29

Outcome: No consensus (leaning against).

WA: I'm leaning against because I don't think it's entirely necessary to have it in P2300, it could be subsequent

POLL: Knowing what we know today, we should continue working on P2300 instead of P0443 to provide structured concurrency for the C++ Standard Library.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	11	2	1	0

Attendance: 29

Outcome: Consensus in favor.

End: 15:37

Summary

Today we continued with our review of P2300, the new senders/receivers proposal.

We started out by discussing properties. Properties were a part of P0443, but P2300 instead uses CPO-based queries.

In P0443, properties could be queried, preferred, or required, and there was a full blown generic property system. Preferring or requiring a property of an executor would give you back a new executor.

In P2300, instead there are CPOs that act as queries, providing the same sort of information that could be accessed in P0443 via properties. However, with P2300 you cannot prefer or require something, you can only query. Additionally, there is no generic property mechanism. CPO queries can be forwarded through layers and can be made to work with type erasure as well.

Some felt that something fundamental is lost without properties. P0443's blocking property was cited as an example. You may wish to do a blocking submission in one part of your program, and a non-blocking submission in another part. The original executors proposals facilitated this by providing a wide API with many different execution functions. This became unwieldy, so properties were introduced as a way to request different semantics from a single execution function.

The P2300 authors believe that this does not represent a loss of capabilities. All of the important properties from P0443 are represented in P2300 as CPO queries. They also questioned the usefulness of requiring or preferring, which assumes that there is a suitable adaptation for the executor. Instead, they believe that one should use different schedulers for different execution semantics, and use queries to assert that the schedulers that have been provided meet the requirements that are needed.

The authors also pointed out that nothing prohibits the addition of more queries or the entire properties system in the future. P2300 does not include it because the authors do not believe it is essential.

We also had a short discussion of the dichotomy of having both a "strictly lazy" and "maybe eager" model in P2300. Some inquired whether we could just have one model of "maybe lazy". The authors explained that this would be problematic, but pointed out that if we want only a single model, "strictly lazy" with explicit eagerization may work. Some questioned the meaning of "eager" and "lazy" in P2300, claiming that both are really just two different forms of laziness. More discussion on this topic is certainly needed.

Finally, we took our first exploratory polls on P2300. We didn't have consensus on whether we felt we needed to have a grand unified model for asynchrony in the C++ Standard Library. We also didn't have consensus on whether we believe that we need to be able to prefer and require capabilities, not just query them. Finally, we had fairly robust consensus that we think that P2300 should replace P0443 as the solution for structured concurrency in the C++ Standard Libray.

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.