Senior Rust Interview

Theme

Q055. What problem does asynchronous Rust solve? ​

Short Answer ​

Async Rust lets a small number of OS threads manage many operations that spend most of their time waiting for I/O, timers, or other events. Instead of blocking a thread, an operation returns Pending, preserves its state, and is polled again when progress is possible. This improves scalability for high-concurrency I/O workloads. It does not inherently speed up CPU-bound work and adds runtime, cancellation, and debugging complexity.

Deep Dive ​

A thread-per-connection model is simple and often sufficient, but very large numbers of mostly idle connections increase stack memory, scheduler work, and context switching. Async code represents each in-flight operation as a compact future and multiplexes many futures over an executor's worker threads.

Async is a workload choice, not a universal replacement for threads. It is strongest for servers, clients, timers, and pipelines with frequent waits. CPU-heavy computation must still consume CPU somewhere and can monopolize an executor worker unless moved to a suitable thread pool.

Rust's model is explicit: futures are lazy, executors are library components, and cancellation commonly occurs by dropping a future. These properties provide control but require care around blocking calls, lock guards, task ownership, and cancellation safety.

Internal Model ​

async fn produces a state machine storing locals that survive suspension. An executor repeatedly polls ready futures. An I/O driver integrates with OS facilities such as epoll, kqueue, or IOCP and wakes tasks when resources become ready.

No thread stack is created per future. The future stores only the state required to resume its computation.

Example ​

rust
use std::time::Duration;

#[tokio::main]
async fn main() {
    let first = tokio::time::sleep(Duration::from_millis(5));
    let second = tokio::time::sleep(Duration::from_millis(5));

    tokio::join!(first, second);
}

Common Mistakes ​

  • Saying async makes CPU-bound work automatically parallel.
  • Assuming every .await creates or blocks an OS thread.
  • Adopting async without considering ecosystem and operational complexity.

Follow-ups ​

  • When is thread-per-connection still a reasonable design?
  • Why are Rust futures called zero-cost abstractions?
  • How does an executor learn that an I/O resource is ready?

References ​

  • Async Book
  • Tokio Documentation
  • Linux kernel documentation