Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: task::scope using implicit scopes #2579

Closed
wants to merge 1 commit into from

Conversation

Matthias247
Copy link
Contributor

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 or scope::spawn_cancellable is
automatically 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 this
is finished.

One drawback of this approach is however that since no ScopeHandle is
available, we also can't tie the lifetime of tasks and their
JoinHandles to this scope. This makes it less likely that we could
borrowing 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:

  • Using tokio::spawn could in the future be equivalent to spawning
    a 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.
  • Shutting down the runtime could be equivalent to leaving a scope: The
    remaining running tasks get a graceful cancellation signal and the
    scope would wait for those tasks to finish.
  • However since the Runtime would never have to force-cancel a task
    (people would opt into this behavior using scope::spawn_cancellable)
    the JoinError could be removed from the "normal" spawn API. It is
    still available for cancellable spawns.

This change adds task::scope as a mechanism for supporting
structured concurrency as described in tokio-rs#1879.

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` or `scope::spawn_cancellable` is
automatically 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 this
is finished.

One drawback of this approach is however that since no `ScopeHandle` is
available, we also can't tie the lifetime of tasks and their
`JoinHandle`s to this scope. This makes it less likely that we could
borrowing 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:
- Using `tokio::spawn` could in the future be equivalent to spawning
  a 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.
- Shutting down the runtime could be equivalent to leaving a scope: The
  remaining running tasks get a graceful cancellation signal and the
  scope would wait for those tasks to finish.
- However since the Runtime would never have to force-cancel a task
  (people would opt into this behavior using `scope::spawn_cancellable`)
  the `JoinError` could be removed from the "normal" spawn API. It is
  still available for cancellable spawns.
@Matthias247 Matthias247 requested a review from carllerche June 2, 2020 06:51
@Darksonn Darksonn added A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-task Module: tokio/task labels Jun 2, 2020
@carllerche
Copy link
Member

I'm going to close this now as there is no way forward. More details here #2596 (comment)

Thanks again for all the work you did on this. Even though we didn't manage to get this through, I personally learned a lot on the topic and from your research. Also, once again, I'm sorry that didn't put more time into this sooner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-task Module: tokio/task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants