Implement P0443/P1897/P2300

[msimberg]

This is a tracking issue for the new and improved P0443 (previous issue was here: https://github.com/STEllAR-GROUP/hpx/issues/2439). As with the previous issue, things are still in progress, so we can't really go all in yet, but we can explore things and see what changes are required.

I'm starting this by collecting the relevant proposals here:

• A Unified Executors Proposal for C++: https://wg21.link/p0443
• One-Way execute is a Poor Basis Operation: https://wg21.link/p1525
• Towards C++23 executors: A proposal for an initial set of algorithms: https://wg21.link/p1897
• Disentangling schedulers and executors: https://wg21.link/p2235
• A General Property Customization Mechanism: https://wg21.link/p1393
• redefine properties in P0443: https://wg21.link/p2220
• std::execution: https://isocpp.org/files/papers/P2300R0.html
• P2300 presentation: https://wg21.link/p2403

Implementations:

• executors-impl: https://github.com/executors/executors-impl
• cudex: https://github.com/jaredhoberock/cudex
• libunifex: https://github.com/facebookexperimental/libunifex

Bulk execution discussion:

• Restore shared state to bulk_execute: https://wg21.link/p1993
• Correcting the Design of Bulk Execution: https://wg21.link/p2181
• Bulk schedule: https://wg21.link/p2209
• A Better bulk_schedule: https://wg21.link/p2224

Related PRs:

• Sender, receiver, operation state: #4665
• Properties: #5033
• More P0443 customization points, simple thread pool executor, P1897 sync_wait and transform: #5053
• P1897 just, just_on, on: #5237

[msimberg]

I have local changes to add the remaining CPOs defined in P0443, and some basic senders/receivers that work on our thread pools. I'll be opening a PR next week...

[msimberg]

Added P2300 (https://isocpp.org/files/papers/P2300R0.html) to the list. It combines P0443 and P1897 into a single paper and cleans up some rough edges.

[hkaiser]

Re P2300: here is a list of things that are changed compared to P0443 and P1897 (please update this list as needed):

There is a new concept of completion-schedulers that may be associated with a particular sender. Thus

• [x] get_completion_scheduler is a new customization point to be implemented for senders (#5487)

General changes:

• [x] transform has been renamed to then (#5644)
• [x] sync_wait should go into the namespace hpx::this_thread (same as std::this_thread::sync_wait) (#5758)
• [x] transfer_just has been added to associate a completion scheduler with just
• [x] added transfer - added unschedule (was removed in R1)
• [x] added bulk (#5422)
• [x] replace sender_traits with completion_signatures_of_t (#5758)
• [x] add run_loop: an execution context that provides a multi-producer, single-consumer, first-in-first-out work queue.
• [ ] add receiver_adaptor: A utility for algorithm authors for defining one receiver type in terms of another.
• [x] add completion_signatures and make_completion_signatures: utilities for describing the ways in which a sender can complete in a declarative syntax (#5758)
• [x] Add a read(query) sender factory for issuing a query against a receiver and sending the result through the value channel. (This is a useful instance of a dependently-typed sender.) (#5748)
• [x] set_done is renamed to set_stopped. All occurances of "done" in indentifiers replaced with "stopped" (#5747, #5758)
• [x] Add customization points for controlling the forwarding of scheduler, sender, receiver, and environment queries through layers of adaptors; specify the behavior of the standard adaptors in terms of the new customization points. (#5748)
• [x] Add get_delegatee_scheduler query to forward a scheduler that can be used by algorithms or by the scheduler to delegate work and forward progress. (#5748)
• [x] Add schedule_result_t alias template. (#5846)
• [x] add awaitables for senders (as_awaitable, with_awaitable_senders), see also #5838
• [ ] sender adaptors (like sender adaptor closure objects, etc.)
• other missing algorithms
  • [x] just_error, just_stopped (#5758)
  • [ ] upon_error, upon_stopped (complementing then)
  • [x] let_stopped (#5758)
  • [ ] on (note new parameter sequence)
  • [ ] into_variant
  • [ ] stopped_as_optional
  • [ ] stopped_as_error
  • [ ] when_all_with_variant, transfer_when_all_with_variant (easy once into_variant is in place)
  • [x] sync_wait_with_variant (#6015)

[msimberg]

The lazy/eager bifurcation was removed from a later revision. @hkaiser I've edited your comment to remove the lazy_ versions (the non-lazy_ versions are now always lazy).

[hkaiser]

This document adds more refinements to P2300 that need to be taken into account: P2532:

• [ ] Remove the default implementation of the get_env receiver query.
• [x] The receiver_of concept takes a receiver and an instance of the completion_signatures<> class template.
• [ ] A receiver’s customization of set_value is required to be noexcept.
• [ ] The sender_to<Sndr, Rcvr> concept requires Rcvr to accept all of Sndr's completions.
• [ ] connect(sndr, rcvr) also requires rcvr to accept all of sndr's completions.
• [x] get_completion_signatures is required to return an instantiation of the completion_signatures class template; the value_types_of_t and error_types_of_t template aliases remain unchanged.
• [ ] The make_completion_signatures design is slightly tweaked to be more general.

[hkaiser]

Changes in P2300R5 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2300r5.html):

Fixes:

• [ ] start_detached requires its argument to be a void sender (sends no values to set_value).

Enhancements:

• [ ] Receiver concepts refactored to no longer require an error channel for exception_ptr or a stopped channel.
• [ ] sender_of concept and connect customization point additionally require that the receiver is capable of receiving all of the sender’s possible completions.
• [x] get_completion_signatures is now required to return an instance of either completion_signatures or dependent_completion_signatures.
• [ ] make_completion_signatures made more general.
• [ ] receiver_adaptor handles get_env as it does the set_* members; that is, receiver_adaptor will look for a member named get_env() in the derived class, and if found dispatch the get_env_t tag invoke customization to it.
• [ ] just, just_error,just_stopped, and into_variant have been respecified as customization point objects instead of functions, following LEWG guidance.

[hkaiser]

There is also:

• [ ] System execution context (wg21.link/p2079), #6089