executor independent spawning

[dvc94ch]

It looks like originally the Context was intended to have an executor attached to it so that you can spawn tasks in an executor independent way. With async-io we no longer need to rely on a specific runtime and wrapping the std types, which is a hughe gain for writing async code that works everywhere. However it is very useful sometimes to be able to spawn a background task. There doesn't seem to be a way to do this without either passing around a "spawner" or deciding on an executor. Is there likely going to be a std::task::spawn that executors can hook in to?

[dvc94ch]

It would actually be rather trivial, the only thing required would be to convince async-std and tokio to register a spawner in their #[async_std::main] and #[tokio::main] macros.

use core::future::Future;
use core::pin::Pin;
use parking_lot::{const_rwlock, RwLock};

type Spawner = fn(Pin<Box<dyn Future<Output = ()> + Send>>);

static SPAWNER: RwLock<Option<Spawner>> = const_rwlock(None);

pub fn register_spawner(spawner: Spawner) {
    let mut lock = SPAWNER.write();
    if lock.is_some() {
        panic!("spawner already registered");
    }
    *lock = Some(spawner);
}

pub fn spawn<F>(future: F)
where
    F: Future<Output = ()> + Send + 'static,
{
    SPAWNER.read().expect("no spawner registered")(Box::pin(future));
}

#[cfg(test)]
mod tests {
    use super::*;

    #[async_std::test]
    async fn test_async_std() {
        fn async_std_spawn(future: Pin<Box<dyn Future<Output = ()> + Send>>) {
            async_std::task::spawn(future);
        }
        register_spawner(async_std_spawn);
        spawn(async {
            println!("spawned on async-std");
        });
    }

    #[tokio::test]
    async fn test_tokio() {
        fn tokio_spawn(future: Pin<Box<dyn Future<Output = ()> + Send>>) {
            tokio::spawn(future);
        }
        register_spawner(tokio_spawn);
        spawn(async {
            println!("spawned on tokio");
        });
    }
}

[dvc94ch]

Here are the corresponding PR's

• Add async-spawner support. async-attributes#19
• Add async-spawner support. tokio-rs/tokio#3161

[taiki-e]

        fn async_std_spawn(future: Pin<Box<dyn Future<Output = ()> + Send>>) {
            async_std::task::spawn(future);
        }

        fn tokio_spawn(future: Pin<Box<dyn Future<Output = ()> + Send>>) {
            tokio::spawn(future);
        }

Note that both are not enough. Both tokio::spawn and async_std::task::spawn return handle, always ignoring it is not the preferred behavior.

[taiki-e]

Also, this seems to only works on global runtime. (and probably only if it is one)
I think there are various other problems. There are some projects that are trying to do something similar, so it's a good idea to look at them and compare them.

[dvc94ch]

Also, this seems to only works on global runtime. (and probably only if it is one)

I'm not sure this is a problem, the idea is that for tests you depend on an executor and use that. But I see that it needs to be failiable in that case like env_logger::try_init.

Note that both are not enough. Both tokio::spawn and async_std::task::spawn return handle, always ignoring it is not the preferred behavior.

This likely involves boxing the joinhandle. I guess it's not something you want to do by default? I can look into this this evening or tomorrow.

[jimblandy]

This proposal is meant to address an important problem: crate authors need a way to spawn without having to take on Tokio and async-std as a dependency that may clash with their users' preferences. The way people are currently forced to choose or compromise introduces both technical friction and social uncertainty, and slows the adoption of Rust async.

But this specific approach is not ideal. People sometimes use both Tokio and async-std in the same application (this is why async-std has the tokio02 and tokio03 features). With this PR, the executor chosen depends on whoever called register_spawner last, so it might even be non-deterministic which executor the neutral-zone spawn ends up invoking.

If the two executors are so similar that a dynamically dispatched, non-deterministic spawn is an acceptable solution for users, then one is led to wonder why they are being forced to choose between two evidently equivalent options in the first place.

In the long run, I think std is going to have to provide a standard spawn. It's just too much of a 'vocabulary' function, like Box or Option, to provide elsewhere.

[dvc94ch]

Actually I think there is precedent. Wouldn't it be similar to the allocator api?

[dvc94ch]

So based on the feedback received so far I made some adaptions

• return a join handle on spawn
• add try_register_spawner to be called from the #[async_std::test] and #[tokio::test] macros

I'd like to note that it is not intended to change the public api of async_std or tokio, registering a spawner is intended to be used only from the macros, being completely transparent to existing users. It is just intended to add an alternative for spawning tasks without having to commit to async-std or tokio.

Also, this seems to only works on global runtime. (and probably only if it is one)

I need some more help understanding in what cases registering more than one executor is a requirement. The suggested api async_spawner::spawn is intended only for cases where it doesn't matter which executor is executing the task, for example when using async-io, or maybe some future reactor based on io_uring.

[yoshuawuyts]

@dvc94ch I think you're doing some interesting research here. The sequence I hope spawn integration in the stdlib will take is:

1. A #[global_executor] tag implemented in userland, that can be used to swap executors backing a single Task / JoinHandle impl (this is what I see you're making progress on, and I think that's exciting!)
2. Eventually land that in userland (may take a while to fix the kinks)
3. Eventually provide a default / fallback executor as part of the stdlib; much like #[global_allocator] has a default.

However the current signature of async_spawner::spawn is:

pub fn spawn<F>(future: F) where
    F: Future<Output = ()> + Send + 'static;

For integration in async-std we need it to be:

pub fn spawn<F, T>(future: F) -> JoinHandle<T> where
    F: Future<Output = T> + Send + 'static,
    T: Send + 'static, 

With an option to later add hooks spawn_local and spawn_blocking as well. A while ago I was experimenting with an implementation of this, but was unfortunately unsuccessful. I couldn't get the spawn and JoinHandle impls to return a type T.

The source of my experiment is here: yoshuawuyts/global-executor-prototype. I would love for someone to be able to finish this up as I think this is a required step in making async Rust more accessible to people. But I'm not sure how feasible the approach in the repo is, or how feasible it'll be to implement in userland.

[dvc94ch]

agnostik works well, I'm quite happy with the solution. All you have to do is use #[agnostik::main], #[agnostik::test] and agnostik::spawn, and it will use the executor that was enabled. I think this issue can be closed.

[dvc94ch]

Reopening. This requires the user to add agnostik as a dependency with a runtime enabled. This is very suboptimal, and I think it will require help from executors to make this seamless.