Asynchronous programming lets a task pause while it waits for I/O so another task can make progress. In a web server, that wait might be for a network connection, file, or database. An async runtime such as Tokio schedules the tasks; it can run multiple tasks on one operating-system thread without assigning a thread to every connection. section 10.1 section 10.3
Compare what happens to three tasks when one encounters a wait: synchronous processing stops at the wait, multithreading can use another operating-system thread, and async processing lets the runtime schedule another task. section 10.1
Two simulated file reads
Start with two independent reads delayed by four and two seconds. Calling them synchronously makes the delays add up to six seconds. A threaded version spawns and joins operating-system threads. The Tokio version introduces `#[tokio::main]`, `async fn`, `tokio::spawn`, `tokio::join!`, and `.await`. Watch the wait itself: the example’s `std::thread::sleep` blocks a thread, so declaring a function `async` does not make that sleep yield. section 10.2 section 10.3
An async function returns a future representing work that can produce a value later. Awaiting it allows that work to progress toward a result. At the executor level, `Future::poll` returns `Poll::Pending` or `Poll::Ready(value)`; a waker tells the executor when to poll a pending task again. A custom timer future demonstrates that pending-to-ready path, though application code can usually use Tokio or Actix Web APIs instead. section 10.3 section 10.5
Reach for async execution primarily when progress depends on I/O rather than CPU computation. Concurrency means tasks can make progress in an interleaved order; it does not necessarily mean they run simultaneously. section 10.3 section 10.6
