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

task: stabilize Builder #4850

Open
2 of 4 tasks
ipetkov opened this issue Jul 20, 2022 · 7 comments
Open
2 of 4 tasks

task: stabilize Builder #4850

ipetkov opened this issue Jul 20, 2022 · 7 comments
Labels
A-tokio Area: The main tokio crate M-runtime Module: tokio/runtime M-task Module: tokio/task

Comments

@ipetkov
Copy link
Member

ipetkov commented Jul 20, 2022

This is a meta issue tracking the stabilization of task::Builder. Outstanding issues to consider:

  • make spawn* methods fallible. Much like std::thread::Builder::spawn is a non-panicking alternative to std::thread::spawn, applications should be able to use task::Builder::spawn* as a non-panicking alternative to tokio::spawn Make task::Builder::spawn* methods fallible #4823
  • is io::Error the correct type to use/stabilize for spawn errors?
  • Fallible spawn methods have not yet landed on a tokio release (1.21 will include them), should we wait for feedback after the breakage before stabilizing?
  • revisit consistency of selfparameter on spawn methods: most take self, but spawn_ontakes &mut self fix incorrect signature in task::Builder::spawn_on #4953
@ipetkov ipetkov added A-tokio Area: The main tokio crate M-runtime Module: tokio/runtime M-task Module: tokio/task labels Jul 20, 2022
@carllerche
Copy link
Member

For the spawn error, we do have additional cases than thread spawning, e.g. "the runtime is shutdown". This makes me think we should introduce a new error type.

We should include 1 or 2 cycles for getting feedback and should put out a call for comments so people know this is coming.

@hawkw
Copy link
Member

hawkw commented Aug 1, 2022

For the spawn error, we do have additional cases than thread spawning, e.g. "the runtime is shutdown". This makes me think we should introduce a new error type.

A SpawnError type can also wrap an io::Error and have it as a source, in the case that the error is not that the runtime is shutdown...

@hawkw
Copy link
Member

hawkw commented Aug 29, 2022

#4955 is another case where, if we added that kind of API, we would be introducing another error variant that doesn't really map directly to an io::Error variant.

I think we may want to have a tokio::task::SpawnError whose source might be an io::Error, rather than returning an io::Error that's internally a SpawnError...

@ipetkov
Copy link
Member Author

ipetkov commented Aug 29, 2022

@hawkw we should probably extend this model to JoinSet as well (return custom errors instead of io::Error)

EDIT: we should apply this to the JoinSet builder which is still unstable

@Noah-Kennedy
Copy link
Contributor

@ipetkov so we were gonna stabilize JoinSet in the next release...

@baxterjo
Copy link

Any update on this? Naming tasks would be useful for my application.

@mox692
Copy link
Member

mox692 commented Jun 1, 2024

FYI, there seems to be similar discussions regarding task names in discord and issue.

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 M-runtime Module: tokio/runtime M-task Module: tokio/task
Projects
None yet
Development

No branches or pull requests

6 participants