Clarify that scheduler returned by get_scheduler on receiver is only valid until the operation completes #112
Labels
bug
Something isn't working
design
needs-proposed-resolution
This issue does not yet have a proposed resolution but needs one
P1
Comments
|
We might want to use the more general wording if get_scheduler is a broader query than just on the receiver. |
|
@lewissbaker are you happy with the wording of my proposed resolution? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 theget_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:
set_xxx(could some schedulers be reference-counting in the destructor?)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]The text was updated successfully, but these errors were encountered: