WIP: task::scope using implicit scopes #2579
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change adds task::scope as a mechanism for supporting
structured concurrency as described in #1879.
This is an alternate implementation compared to #2576.
This version of the scope implementation makes use of implicit scopes,
which are propgated within the task system through task local storage.
Ever task spawned via
scope::spawn
orscope::spawn_cancellable
isautomatically attached to it's current scope without having to
explicitly attach to it. This provides stronger guarantees, since child
tasks in this model will never be able to outlive the parent - there is
no
ScopeHandle
available to spawn a task on a certain scope after thisis finished.
One drawback of this approach is however that since no
ScopeHandle
isavailable, we also can't tie the lifetime of tasks and their
JoinHandle
s to this scope. This makes it less likely that we couldborrowing data from the parent task using this approach.
One benefit however is that there seems to be an interesting migration
path from tokios current task system to this scoped approach:
tokio::spawn
could in the future be equivalent to spawninga task on the runtimes implicit top level scope. The task would not
be force-cancellable, in the same fashion as tasks spawned via
scope::spawn
are not cancellable.remaining running tasks get a graceful cancellation signal and the
scope would wait for those tasks to finish.
(people would opt into this behavior using
scope::spawn_cancellable
)the
JoinError
could be removed from the "normal" spawn API. It isstill available for cancellable spawns.