Is there a lower-latency way of responding to an event than spinning/busy-waiting?

• tokio-uring

  28 998 4.1 Rust

  An io_uring backed runtime for Rust

  

So back to the title: is there a lower-latency way of responding to an event than spinning/busy-waiting? Or more generally, what's the fastest possible way to respond to an I/O event? I have never played with io_uring but this Tokio RFC looks promising. Could io_uring be faster than busy-polling? Or can busy-waiting be used on top of io_uring?

• sleeping_vs_spinning

  1 26 1.9 Rust

  Benchmarks to measure the cost of sleeping

All the code is available on GitHub: https://github.com/felix-pb/sleeping_vs_spinning

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• tokio

  196 24,677 9.5 Rust

  A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...

  

Asynchronous Rust (e.g. with Tokio) is great for dealing with a large number of events (e.g. for web servers), but here I am specifically asking about how to respond as fast as possible to a small number of events (e.g. one event at a time every 100ms). I wrote a simple benchmark for 3 common abstractions in Rust's standard library:

• core-isolation

  2 5 0.0 Rust

  Presentation at Lund LinuxCon 2017

You might be interested in my presentation about low latency audio here: https://github.com/diwic/core-isolation

Suggest a related project