Comparison of Rust async and Linux thread context switch time and memory use

Re:Comparison of Rust async and Linux thread context switch ... by masklinn on Friday February 12, 2021 @05:09AM (#26112097)

> 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?

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by Freaky on Friday February 12, 2021 @10:50AM (#26114941)

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/ceba324bef9641d61...

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by josephg on Friday February 12, 2021 @07:49AM (#26113068)

> 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

[ Parent | on HN ]