Runtime-agnostic cooperative task scheduling budget

[withoutboats]

(NOT A CONTRIBUTION)

@matklad

A different force is a push back against just adding stuff to the language/stdlib incrementally, without considering the big picture, and far future of Rust. Here, I am very willing to say "let's maybe keep this outside of std", as crates.io is almost always an adequate (if not perfect) way to relive the pressure.

Yea, these are clearly two forces in tension in any project. But I feel very comfortable saying which of these forces the Rust project is too biased towards.

@matklad

The Context API is actually a good case study here. IIRC, originally we wanted to not have Context at all, just waker. Then we added it, but with Send + Sync bound because "single threaded executors can use array and indexes". Recently we relaxed that via a technically breaking change. What's the end story for the Context API?

This isn't quite a correct recounting.

We got rid of LocalWaker and just went with Waker on the basis that single threaded executors can use arrays and indexes. At the time our narrative around single threaded executors was that they were strictly for embedded systems that wouldn't want to use an Rc waker anyway. Of course, the renewed interest in thread-per-core has shown this is wrong.

But this all happened before Context was added. Adding Context was fully driven by the tokio project, as future proofing to support exactly the kind API I'm proposing now. Frankly, within the async WG we didn't think it was necessary, and really forfeited this discussion in order to get buy in on shipping. So the reason Context wasn't Send + Sync was a total oversight, probably in large part because we thought it was unnecessary in the first place.

And we were totally wrong! Context, correctly defined, enables us to add these APIs to the task system to support different kinds of runtimes, both LocalWaker and this thing. Adding Context, and fixing our mistake in defining it, was the right call and now is enabling different use cases. Like I'm not that enthusiastic about thread-per-core and I think work stealing is the right default, but I think its very important that Rust support either model because Rust is supposed to give end users total control over their systems.

So I think the end story for the context API is exactly what I'm proposing here and what has been proposed with the LocalWaker extension: bringing functionality into std that's got clear motivation and API consensus from the ecosystem to support different kinds of async task systems. Ideally, we'd eventually get rid of runtimes using thread locals at all, but that's a long journey.