SYSTEM Cited by 2 sources

Tokio

Tokio is the dominant async runtime for Rust (tokio.rs, crate tokio). It integrates Rust Futures with an OS event loop (epoll on Linux, kqueue on BSD/ macOS) so poll-driven state machines only get re-polled when something they care about has actually progressed. The Waker passed to each poll call is the handle the Future uses to wake itself back up through the runtime.

Fly.io's [[sources/2025-02-26-flyio-taming-a-voracious-rust-proxy|2025-02 proxy incident]] gives a usefully terse summary of the model:

"A Future is a type that represents the future value of an asynchronous computation… Futures are state machines, and they are lazy: they expose one basic operation, poll, which an executor (like Tokio) calls to advance the state machine. That poll returns whether the Future is still Pending, or Ready with a result… Tokio integrates Futures with an event loop and, when calling poll, passes a Waker. The Waker is an abstract handle that allows the Future to instruct the Tokio runtime to call poll, because something has happened."

This framing is load-bearing for the rest of that source — every Fly.io bug discussed there is a Waker-level mis-signal that collapses the whole abstraction to busy-polling.

Seen in

• sources/2025-02-26-flyio-taming-a-voracious-rust-proxy — contextual primer. Tokio itself is not the bug; it is the execution substrate that makes Future / Waker / AsyncRead semantics load-bearing. When a TlsStream mis-handles its Waker, Tokio faithfully drives the busy- poll cycle the mis-handling demands — which is exactly what shows up as 100% CPU in the flamegraph.

Related

• systems/rustls / systems/tokio-rustls — the TLS path that plugs into Tokio via the async adapter.
• systems/fly-proxy — built on Tokio.
• concepts/async-rust-future — the state-machine primitive Tokio drives.
• concepts/rust-waker — the wake-up handle Tokio passes into poll.
• concepts/asyncread-contract — the streaming-IO extension most network code uses.
• concepts/spurious-wakeup-busy-loop — the pathology that appears when a Future lies to Tokio about its readiness.
• companies/flyio
• sources/2025-05-28-flyio-parking-lot-ffffffffffffffff — Tokio explicitly ruled out as a source of the parking_lot-RwLock bug: "parking_lot locks are synchronous, but we're a Tokio application; something somewhere could be taking an async lock that's confusing the runtime. Alas, no." Useful negative result — async runtimes and synchronous locks can coexist correctly when used carefully, and the wrong place to look for a synchronous-lock bug is the async runtime. Also reinforces the wider wiki framing that parking_lot locks are synchronous primitives even though Fly uses them from a Tokio application.