async fn read_to_string(path: impl AsRef<Path>) -> io::Result<String> {
std::fs::read_to_string(path)
}
It doesn't have await inside! My mind was blown as I saw that. async fn read_to_string(path: impl AsRef<Path>) -> io::Result<String> {
std::fs::read_to_string(path)
}
It doesn't have await inside! My mind was blown as I saw that.> This blog post describes a proposed scheduler for async-std that did not end up being merged for several reasons.
I don't think it's a particularly good idea in the first place - it's basically an automatic watchdog-driven block_in_place(). It doesn't remove the problem of blocking in futures, it just limits the damage to the local task rather than blocking the entire executor.
That's fine in the simple case of future-per-task, but it's pretty common to be polling multiple futures concurrently within one, so it's not a general solution.
That is a super interesting strategy, though obviously only works when you can « afford » a multithreaded scheduler.
Anyway I wonder how they manage this, signals?
Yeah, for example in comparison actix-web only uses single threaded workers - one per core. Future in actix-web doesn’t have to be Send or Sync, and I think it’s incompatible with what async-std is doing here. That design is almost certainly one of the reasons actix-web tops phoronix
Each worker thread runs in a loop executing a queue of jobs. On every iteration it sets an atomic progress flag to true.
The runtime in which it's contained polls its workers every 1-10ms, atomically swapping in false and checking to see if the previous value was also false - if so, it steals its task queue and spins up another worker to execute it.
https://github.com/async-rs/async-std/blob/ceba324bef9641d61...