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?

[Darksonn]

We already have something like that in tokio-util: LocalPoolHandle. However, Tokio runtimes generally do not pin futures to specific threads, so our futures have to be Send, meaning that there is no advantage of closures.

Make workstealing executors unsafe to construct... until the language developers "fix" this issue of entangling of Send with OS threads

Workstealing is the best default for an executor. We certainly wouldn't want that to be unsafe.

Besides, all of this is moot. We can't make backwards-incompatible changes.

[NawfelBgh]

Tokio runtimes generally do not pin futures to specific threads, so our futures have to be Send, meaning that there is no advantage of closures.

In fact, there is a DX win to be had.

I think that Tokio should offer another multithreaded executor that pins tasks to threads. This executor shall use the spawn function proposed by @matklad which makes writing code like this possible (copied from the blog post) :

async fn f(context: &Context) {
  g(context).await;
  context.increment();
}

async fn g(_context: &Context) {
}

Workstealing is the best default for an executor. We certainly wouldn't want that to be unsafe.

The users of the work stealing executor can not benefit from the DX offered by the closure-consuming spawn function because thread locals make that spawn function not safe to expose.

But the new muti-threaded task-pinning executor can use @matklad's async spawn function delivering better DX to those of us who do not think that work stealing is essential to handling our workloads. Sometimes it's fine to just distribute tasks fairly between the worker threads.

[matklad]

I would like to also point out that the overall strategy of encouraging runtimes to do something to force the language developers to do something feels unnecessary adversarial. We all are language designers, if we think something is amiss, we could ourselves spearhead the change through Rust open development process.

My personal views here are:

• There is something amiss here. It does seem problematic that complicated language machinery (return type notation, trait transformers) is being designed right now primarily to enable compiler to reason about Send-ness of futures generically, while this property doesn't seem fundamentally useful, and is more of an artifact of an implementation.
• This might, or might not be fixable given Rust backwards compatibility constraints. It's ok if it's not fixable, but, if it is, this should be at least explored.
• It might even be the case that, starting from scratch, the current design is still optimal, as there is a tradeoff here between thread locals and work stealing. I do think that "thread locals are unsafe" would be a better overall design, if we start from scratch, but I am not very confident in that opinion.
• The action items here are two pronged:
  • Write a specific RFC detailing exact changes to remedy the situation
  • Write a PR to rust-lang/rust implemented proposed changes
• Crucially, these two things don't require (although could benefit from) coordination from the lang team or compiler team. Teams involvement will be necessary to make a decision, but we are not at the point yet where it's clear what the decision could be. My blog post is intentionally hand-waving, it misses the actual design work
• I don't intend to drive the required design work myself :)

[Fishrock123]

As I mentioned over in async-rs/async-std#1072

---

Offer another multithreaded executor that pins tasks to threads.

Interestingly, this is an option that CloudFlare's pingora async runtime supports (built on top of tokio).

And their runtime has this comment in the source code:
https://github.com/cloudflare/pingora/blob/acee67f87020ef41267fe475bcc5cbed44782a06/pingora-runtime/src/lib.rs#L15-L24

//! Pingora tokio runtime.
//!
//! Tokio runtime comes in two flavors: a single-threaded runtime
//! and a multi-threaded one which provides work stealing.
//! Benchmark shows that, compared to the single-threaded runtime, the multi-threaded one
//! has some overhead due to its more sophisticated work steal scheduling.
//!
//! This crate provides a third flavor: a multi-threaded runtime without work stealing.
//! This flavor is as efficient as the single-threaded runtime while allows the async
//! program to use multiple cores.