task: stabilize Builder

[ipetkov]

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

[carllerche]

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]

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]

#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]

@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]

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