Open
Description
Thursday Dec 02, 2021 at 21:11 GMT
Originally opened as NVIDIA/stdexec#295
Similar to the wording in the get_stop_token() CPO, which only guarantees that the token returned is valid until the operation completes, we should do the same for the get_scheduler() CPO.
We should be careful to clarify what operations are valid after calling set_xxx on the receiver.
e.g. is it valid to call:
- the destructor of the scheduler after
set_xxx(could some schedulers be reference-counting in the destructor?) - the move constructor?
- the
schedule()CPO (but just not connect/start it)
Another possibility is to tie the end-of-validity of the scheduler to the destructor of the receiver (or move-constructed copy of the receiver).
Proposed resolution:
Change [exec.recv.concepts] p3 as follows:
3. Let rcvr be a receiver and let op_state be an operation state associated with an
asynchronous operation created by connecting rcvr with a sender.
- Let token be a stop token equal to get_stop_token(get_env(rcvr)). token shall
- remain valid for the duration of the
+ Let o be an object equal to Q(get_env(rcvr)) where Q is one of:
+ * get_allocator
+ * get_stop_token
+ * get_scheduler
+ * get_delegation_scheduler.
+ o shall remain valid for the duration of the
asynchronous operation's lifetime ([exec.async.ops]).
[Note 1: This means that, unless it knows about further guarantees provided by the
- type of rcvr, the implementation of op_state cannot use token after it executes a
+ type of rcvr, the implementation of op_state cannot use o after it executes a
completion operation. This also implies that any stop callbacks registered on
- token
+ rcvr's stop token
must be destroyed before the invocation of the completion operation. — end note]