Open
Description
There are use-cases where an operation does not natively support cancellation but where a consumer wants to be able to detach promptly from waiting for the operation to complete when the result is no longer required.
The existing nest() basis operation that is proposed by the async_scope paper has the semantics that it just forwards the stop-request to the nested operation and waits for it to complete.
As detaching from an operation leaves that operation to continue running in the background, the detachable operation needs to be associated with an async-scope so that we can at least later join that detached work.
The semantics of a detach_on_cancel() operation would be:
sender auto detach_on_cancel(sender auto&& sender, async_scope_token scope);When invoked:
- tries to increment the ref-count on the scope-token, if successful, returns a sender that holds a ref-count and the input sender.
- when the returned sender is connected, allocates storage for the operation-state using the allocator obtained from the connected receiver's environment. i.e. using
get_allocator(get_env(r)), and then constructs the operation-state into that storage. - when the returned operation-state is started, then starts the underlying operation
- if a stop-request is received before the underlying operation completes, then sends a stop-request to the underlying operation and then detaches the consumer from the underlying operation. The underlying operation-state and heap-allocated storage are destroyed/freed when the operation eventually completes. Then after the allocation is freed, the ref-count is decremented.
- otherwise, if the operation completes before a stop-request is issued, then the result is forwarded to the receiver connected to the detach-on-cancel-sender and the allocation/ref-count is freed when the detach-on-cancel-operation-state is destroyed.