3 ms·

Btw, have you read this: https://async.rs/blog/stop-worrying-about-blocking-the-new-async-std-runtime https://async.rs/blog/stop-worrying-about-blocking-the-new

Btw, have you read this: https://async.rs/blog/stop-worrying-about-blocking-the-new-async-std-runtime https://async.rs/blog/stop-worrying-about-blocking-the-new-a... async-std allows to run blocking calls without hoops rather efficiently: 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.

masklinn 6y ago
> should a task execute for too long, the runtime will automatically react by spawning a new executor thread taking over the current thread’s work. 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?
- josephg 6y ago
  > though obviously only works when you can « afford » a multithreaded scheduler. 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
- Freaky 6y ago
  Nothing so fancy. 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/ceba324bef9641d61239ed68a2f6671f59fa2831/src/rt/runtime.rs#L107-L153 https://github.com/async-rs/async-std/blob/ceba324bef9641d61...
raggi 6y ago
It also really doesn't scale. It'll do fine on your average <10 core laptop, but once you get on a multi-package system you're going to find you're constantly thrashing memory because it is making disruptive scheduling decisions and your pooled tasks have poor context locality.
Freaky 6y ago
Read the first sentence. > 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.

masklinn 6y ago

> should a task execute for too long, the runtime will automatically react by spawning a new executor thread taking over the current thread’s work. 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?

josephg 6y ago
> though obviously only works when you can « afford » a multithreaded scheduler. 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
Freaky 6y ago
Nothing so fancy. 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/ceba324bef9641d61239ed68a2f6671f59fa2831/src/rt/runtime.rs#L107-L153 https://github.com/async-rs/async-std/blob/ceba324bef9641d61...

raggi 6y ago

It also really doesn't scale. It'll do fine on your average <10 core laptop, but once you get on a multi-package system you're going to find you're constantly thrashing memory because it is making disruptive scheduling decisions and your pooled tasks have poor context locality.

Freaky 6y ago

Read the first sentence. > 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.