Make async spawn take a closure

[NawfelBgh]

Hello,

I'm posting this idea to many Rust async runtimes discussion threads in order to push for the alternative design of the task spawn API described by @matklad in https://matklad.github.io/2023/12/10/nsfw.html

// std::thread::spawn
pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T + Send + 'static,
    T: Send + 'static {}

// A hypothetical better async spawn
pub fn spawn<F, Fut>(f: F) -> JoinHandle<Fut::Output>
where
    F: FnOnce() -> Fut + Send + 'static,
    Fut: Future,
    Fut::Output: Send + 'static {}

If you think that this is the right direction for rust to take, I suggest to do the following to arrive at the destination ASAP:

1. change task spawn definition to one that takes a closure returning a future
2. Provide a safe executor constructor that pins tasks to threads
3. Make workstealing executors unsafe to construct... until the language developers "fix" this issue of entangling of Send with OS threads

What do you think?

[notgull]

I'm not sure what problem is actually solved by this. You still aren't able to share non-Send data between tasks. Even with this proposal you can't share, say, an &Cell<i32>, across two separate tasks. So for the example given in the blog post making the closure Send but the future !Send, sharing a cell wouldn't work. So you can't do this:

let cell: Cell<i32> = Cell::new(0);
let ex = Executor::new();

let t1 = ex.spawn(async {
    cell.set(1);
});
let t2 = ex.spawn(async {
    cell.set(2);
});

I guess that if you instantiate the thread-unsafe data in the closure, then it would work better. However I think that use case is pretty niche?

If spawn took a closure, I guess polling two futures on the same task would work. But I can't see a real-world use case for this.

use futures_lite::prelude::*;

let t = ex.spawn(|| {
    let cell = Cell::new(0);

    let f1 = async {
        cell.set(1);
    };
    let f2 = async {
        cell.set(2);
    };

    f1.or(f2).await;
});

@matklad, I feel like there's something I'm missing here. I'm always looking to improve smol's ergonomics; hell if it coincides with the release of futures v0.4 I'm happy to make it a breaking one. But I'm not sure if I see what the desired problem to fix is.

[NawfelBgh]

If I get the idea of the blog post right, the following task will give you an error when using an executor with multiple worker threads:

    use futures_lite::prelude::*;

    const android: i32 = 16;

    async fn feed_it_an_android(cell: &Cell<i32>) {
        cell.set(android);
    }

    async fn assert_is_perfect(cell: &Cell<i32>) {
        // assert
    }

    let t = ex.spawn(async {
        let cell = Cell::new(0);
        feed_it_an_android(&cell).await;
        assert_is_perfect(&cell).await;
    });

Where as the sync version of the code works fine:

use std::{cell::Cell, thread::{spawn}};

fn main() {    
    const android: i32 = 16;

    fn feed_it_an_android(cell: &Cell<i32>) {
        cell.set(android);
    }

    fn assert_is_perfect(cell: &Cell<i32>) {
        // assert
    }

    spawn(|| {
        let cell = Cell::new(0);
        feed_it_an_android(&cell);
        assert_is_perfect(&cell);
    });
}

[notgull]

Ah, okay. That makes a lot more sense.

I don't have enough sleep at the moment to rationally review this proposal, clearly. Give me some time.

[NawfelBgh]

As middle ground, maybe we could have a muti-threaded executor that doesn't do work-stealing, and which uses @matklad 's spawn API delivering a better DX while paying some potential performance loss.

Btw, I got some other replies in this tokio discussion thread: tokio-rs/tokio#6346