-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Comments
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. |
A |
#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 I think we may want to have a |
@hawkw we should probably extend this model to EDIT: we should apply this to the |
@ipetkov so we were gonna stabilize |
Any update on this? Naming tasks would be useful for my application. |
This is a meta issue tracking the stabilization of
task::Builder
. Outstanding issues to consider:spawn*
methods fallible. Much likestd::thread::Builder::spawn
is a non-panicking alternative tostd::thread::spawn
, applications should be able to usetask::Builder::spawn*
as a non-panicking alternative totokio::spawn
Maketask::Builder::spawn*
methods fallible #4823io::Error
the correct type to use/stabilize for spawn errors?self
parameter on spawn methods: most takeself
, butspawn_on
takes&mut self
fix incorrect signature in task::Builder::spawn_on #4953The text was updated successfully, but these errors were encountered: