liveBook · Manning

Async runtime

As explained in Rust Servers, Services, and Apps

An asynchronous runtime is software that schedules and executes nonblocking asynchronous operations and tasks.

An async runtime schedules tasks while they wait for external events. With Tokio, a task waiting for file, network, or database I/O can yield so another task runs; when the event completes, the runtime can schedule the original task again. This is most useful for I/O-bound work, not necessarily CPU-bound computation. section 10.1 section 10.3

A Tokio task moves through a small execution cycle:

  • An async function creates a future. Calling it alone does not run its body; the example’s simulated file reads produce no output until they are awaited. section 10.2
  • The executor polls the future. Poll::Pending means it cannot return a value yet; Poll::Ready contains its result. section 10.4
  • A Waker notifies the runtime when a pending task should be polled again. section 10.4
pub trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

The Future trait’s poll signature shows the interface the executor uses: a pinned future, a task context, and a Poll result. section 10.3 section 10.4

Spawn two file-read tasks

In src/main.rs, annotate async main with #[tokio::main], launch each operation with tokio::spawn, await each async file-read function inside its task, and use tokio::join! to wait for both handles. Omitting .await leaves the functions unexecuted. The sample reads are simulated with std::thread::sleep(), so they illustrate task structure rather than a fully nonblocking I/O implementation. section 10.2 section 10.5

To see why waking matters, implement a timer as a custom Future. Its poll method returns Poll::Pending before an expiration time, arranging for a Waker to notify the executor later; once the time has passed, it returns Poll::Ready. An always-pending future never finishes, while repeatedly waking it without progress causes repeated polling. section 10.4 section 10.5

For a web service, the runtime lets work continue while requests wait on I/O. Actix Web combines worker threads with async I/O and uses a Tokio-based runtime; this differs from assigning a separate operating-system thread to every connection. section 10.3 section 3.3

How Rust Servers, Services, and Apps covers it

How deep it goes
Explains executor polling, waking, and a custom timer Future, while deferring a full explanation of pinning.
Examples
Contrasts simulated sequential and concurrent file reads, then builds a timer Future with an expiration time.
What it assumes
Assumes basic Rust and Cargo use while introducing async functions, awaiting, and futures through small programs.
What you can do after
Apply it via Tokio: spawn and join async tasks, then implement a Future that wakes the executor when ready.
How it connects
Connects async runtimes to futures, Wakers, concurrency, multithreading, and Actix Web.

Also explained in

Compare how 2 books explain async runtime →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Rust Servers, Services, and Apps. The section links point to the parts of the book it draws on.