3 ms·
The main thing I don't understand about Rust's async/await situation is how it's not very inefficient on the CPU given that it fundamentally uses polling? https
by sdegutis 6y ago
The main thing I don't understand about Rust's async/await situation is how it's not very inefficient on the CPU given that it fundamentally uses polling? https://doc.rust-lang.org/std/future/trait.Future.html https://doc.rust-lang.org/std/future/trait.Future.html
- carllerche 6y agoThe model is very similar to how epoll works. The executor does not poll futures in a loop. Between polls, the executor waits for a readiness notification. If `Future::poll` returns Pending, once it becomes ready to do more work, it notifies the executor, the executor then schedules the future to be polled again.
- mamcx 6y agoI suspect that a big part of the design of this api (and why it take time) was exactly to be as performant as possible. The compiler desugar the async/await to state machines and that is melted away by regular means. Also, the quality of the runtime elected must take some credit.
- aliceryhl 6y agoIt doesn't poll all the time. The context parameter contains a walker, and you have to tell the executor to wake you up using that waker when you are ready to continue.