P2235 Disentangling Schedulers and Executors

[brycelelbach]

P2235R0 Disentangling Schedulers and Executors (Ville Voutilainen)

[brycelelbach]

2020-10-19 Library Evolution Telecon Minutes

Chair: Nevin Liber

Champion: Ville Voutilainen

Minute Taker: Ben Craig

[brycelelbach]

2020-10-22 Library Evolution Telecon Minutes - Final Pre 2020 Fall Polls Discussion

Chair: Bryce Adelstein Lelbach

Champion: Ville Voutilainen

Minute Taker: Ben Craig

Start P2235 Presentation: 2020-10-22 12:06 Pacific

End P2235 Presentation, Start Discussion of P2235: 12:17

What should make_scheduler_from_executor do with a type that satisfies
scheduler and executor? Just return the type?

What happens when you have the following, and want to pass something that
satisfies both scheduler and executor?

void f(executor);
void f(scheduler);

It's already ambiguous in P0443; this paper doesn't make it any more ambiguous.

If schedulers/senders/receivers and executors are disentangled, should they remain in the same proposal?

Some wonder if we still need executors if we have schedulers/senders/receivers.

Papers are welcome on removing either executors or schedulers/senders/receivers, but they're not on the docket today.

If we adopt P2235 and disentangle schedulers and executors, do the operations still need to be CPOs?

End Discussion of P2235: 13:03

SUMMARY: We discussed P2235, which proposes removing implicit adaptation between schedulers and executors. First, we discussed writing distinct overloads for scheduler and executor. We determined that this is not supported by P0443 today, and P2235 does not change that. Much of our discussion revolved around a tangential topic; why do we have both executors and schedulers, and do we need both? We did not reach the end of this topic, but reached the following conclusions:

• Removing either would reduce consensus in Library Evolution and SG1.
• Executors closely match prior art in what platform vendors provide.
• Further research is needed to determine what kinds of algorithms can be implemented with both models and what limitations exist.
  Our preference is to defer this discussion until a future date, when we have a revision of P0443 that incorporates all of the changes and feedback from the 2020 Summmer Library Evolution review. Concrete papers and field experience on these topics are necessary as well.

OUTCOME: We will commence 2020 Fall Library Evolution polling as planned.

[brycelelbach]

2020 Fall Library Evolution Polls

P2262: 2020 Fall Library Evolution Poll Outcomes

POLL 0: Remove implicit adaptation from P0443R14 (Executors) by applying P2235R0 to P0443R14, which will make schedule only take schedulers, make execute only take executors, make sender and receiver operations like connect only take senders and receivers, and add explicit adaptation from executor to scheduler (make_scheduler_from_executor) but not vice versa.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
21	15	0	0	0

Outcome: Unanimous consensus in favor.

POLL 1: Use one class for each individual trait instead of combined traits classes (sender_traits, etc) in P0443R14 (Executors).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	7	7	5	2

Outcome: No consensus.

POLL 2: Remove static_thread_pool from P0443R14 (Executors). It may be pursued in a follow-on proposal.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
8	11	4	7	2

Outcome: Weak consensus in favor.

POLL 3: Remove any_executor from P0443R14 (Executors). It may be pursued in a follow-on proposal.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	9	4	4	2

Outcome: Consensus in favor.

POLL 4: Remove any_executor::target and any_executor::target_type from P0443R14 (Executors).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
12	10	4	2	0

Outcome: Consensus in favor.

POLL 5: P0443R14 (Executors) is sufficiently mature that we should aim to ship it in C++23.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	12	7	10	1

Outcome: Weak consensus in favor.

Outcome

Revise P0443R14 (Executors) as follows and return to Library Evolution for further review:

• Apply P2235R0.
• Remove static_thread_pool. A separate follow-on proposal for static_thread_pool is encouraged.
• Remove any_executor. If any_executor is pursued in the future, any_executor::target and any_executor::target_type shall be removed.

We will continue on our planned course of aiming to ship P0443R14 (Executors) in C++23, but a notable minority in Library Evolution are not convinced that P0443R14 (Executors) is sufficiently mature. Library Evolution wants to see more field experience with P0443R14 (Executors). P0443R14 (Executors) authors and advocates should take note of this. Focus on demonstrating field experience through implementations and usage, improving introductory material, minimizing the scope, resolving outstanding minor open issues, and developing wording to increase Library Evolution confidence in the maturity of P0443R14 (Executors).

We encourage a separate follow-on proposal exploring individual traits versus combined traits classes in general, using P0443R14 (Executors) as an example to gauge impact.