LeeHowes

~destructor(); // UB if outstanding schedulers are used after destruction. Terminates if there is outstanding work.
spawn(sender)->allocate<sender<Values…>>;  // spawns on a scheduler that the async_scope is aware of
spawn_now(sender)->void;  // spawns on a scheduler that the async_scope is aware of, blocks until allocate is satisfied
spawn_ignore(sender)->allocate<>. // spawns on a scheduler that the async_scope is aware of. This is the fire and forget version.
async_join()->sender;  // name TBD, I find unifex’s names confusing, Kirk doesn't like join though.
async_stop_and_join()->sender;  // name TBD, I find unifex’s names confusing, Kirk doesn't like join though.
get_scheduler()->scheduler; 
get_stop_token()->stop_token; 
?? request_stop() // not clear if that's necessary with the join variant; but unifex has it
?? spawn_call_now(Func)->void; // to allow us to drop execute()

LeeHowes

A lazy simplification of P0443

Summary

This paper seeks to add support for lazy task creation and deferred execution to P0443, while also simplifying the fundamental concepts involved in asynchronous execution. It seeks to do this as a minimal set of diffs to P0443. It achieves this by replacing P0443's six Executor::*execute() member functions with two lazy task constructors that each return a lazy Future-like type known as a "Sender". Work is actually enqueued by calling submit() on a Sender.

Background

P0443 presents a unified abstraction for agents of asynchronous execution. It is the result of a long collaboration between experts from many subdomains of concurrent and parallel execution, and achieved consensus within SG1 and, to some degree, LEWG. Although there were known gaps in the abstraction, there were papers in flight to address them, and for all intents and purposes P0443 seemed on-target for a TS or, possibly even C++20.

LeeHowes

Compromise part 2 - a lazy simplification of P0443

This document arose out of offline discussion largely between Lee, Bryce and David, as promised during the 2018-08-10 executors call.

The discussed compromise is that we should replace the enqueue functions with a limited set of lazy task factories. Any syntactic cost of providing a trivial output receiver to these operations can be hidden in wrapper functions. We do not expect a runtime cost assuming we also provide a trivial parameter-dropping receiver in the standard library that the implementation can optimize against.

By passing a full set of parameters to a task construction functions, any task we place in a task graph may be type erased with no loss of efficiency. There may still be some loss of efficiency if the executor is type erased before task construction because the compiler may no longer be able to see from the actual executor into the passed functions. The earlier we perform this operation, however, the more chance there is of making this

LeeHowes

P1055 and P0443 - a compromise

Summary

The goal here is to provide a minimal set of changes to P0443 that allows us to aim for a clean, lazy-by-default API, that does not drastically change the expectations of the P0443 authors.

I am making a few assumptions in writing this:

• I am not worrying about bikeshedding names. Where appropriate I will use names from P0443 even if they don't really make sense any more as names. We can change them.
• I believe we may wish to tweak the particular parameters to the bulk execute operation. We will likely also want other types of task such as a value + error task as I described in P1054. I do not worry about that here.
• I do not expect changes to the properties mechanism except in so much as the types they return may differ slightly.