Async-std: Provide futures::task::Spawn implementation

[Nemo157]

To support executor agnostic libraries it would be useful to have a handle that can be passed to them if they require the ability to spawn new tasks.

[skade]

This would make us rely on futures types in the public interface, which we don't want to do. That's not only for the Spawn type, but also all Error types and FutureObj.

A spawner is also pretty simple to write and I'd prefer frameworks to ship their own if they want to. An example for the patters library would be useful, though.

[Nemo157]

async-std already exposes types from futures in the public interface, passing an async_std::fs::File to a function accepting impl futures::io::AsyncRead works. Spawn is currently defined in futures-core so it is positioned as even more stable than the IO traits (although there is an issue open about moving it out of there https://github.com/rust-lang-nursery/futures-rs/issues/1830).

A spawner is also pretty simple to write and I'd prefer frameworks to ship their own if they want to.

A ZST spawn impl calling out to a global function is trivial to write, I just don't see why that should be repeated 100's of times across every application that wants to call into an executor-agnostic library when it can be provided by the executor. I guess someone could publish async-std-spawn and everyone can just depend on that instead.

[skade]

@Nemo157 yes, but it explicitly rules out those types from its stability guarantees.

It's precisely the open issues that make it hard for us to currently commit on these. An async-std-spawn would be perfectly great in that line of thinking, even one published and maintained by this project itself, to be clear!

[Nemo157]

I should also say that there is also tokio::executor::{Executor, TypedExecutor} which are being used by some crates like hyper currently. So it probably makes a lot of sense to provide separate adaptor crates until there has been more experimentation and the ecosystem has stabilized a bit.

[skade]

Yes. I want to generally write down a strategy/contribution document for such things soon (tm) to bring some clarity into this.

[yoshuawuyts]

The code for this would probably be along the lines of:

#[derive(Debug)]
struct Spawner;

impl futures::task::Spawn for Spawner {
    fn spawn_obj(&mut self, future: FutureObj<'static, ()>) -> Result<(), SpawnError> {
        async_std::task::spawn(future)?; // cast the error somehow
        Ok(())
    }
}

I agree having a separate for this would be convenient. @Nemo157 is this something you would want to author?

[Nemo157]

Unfortunately I'm not using async-std enough in real projects to have the motivation to maintain a crate for that.

[yoshuawuyts]

@nemo157 that makes sense; thanks for the quick reply!

[yoshuawuyts]

It doesn't seem anyone is particularly eager to implement this anytime soon. Also the Spawn trait might be removed from futures-core in the near future. I think it's okay to go ahead and close this for now.