Runtimes

// execution-models

Execution Models

Every language needs a way to turn source code into running instructions. That "way" is the execution model, and it fundamentally determines startup time, peak performance, memory usage, and portability. The six families below cover essentially every language on the PL Timeline.

// diff --side-by-side

Side-by-Side Comparison

A quick overview of the key trade-offs between execution models. Every choice is a compromise: native compilation gives you peak speed but locks you to a target; interpreters start instantly but pay for it every instruction.

// from source to execution

The Big Picture

To tie it together: all execution models are variations on the same pipeline. The key question is when compilation happens and how many layers sit between your source code and the CPU.

// std::thread vs async fn

Synchronous vs Asynchronous (Rust)

Rust is unusual in giving you both models as first-class citizens with zero runtime by default. Synchronous code uses real OS threads and blocking calls: simple and perfect for CPU work. Asynchronous code uses async/.await plus an executor (Tokio, smol…) that polls tasks, cooperatively multiplexing millions of them onto as few as one thread: the right tool when you're I/O-bound. Threads are not inherent to async; a multi-thread executor is just an added optimization. Neither model is "better"; they solve different problems.

use std::thread;

fn main() {
    let mut handles = Vec::new();
    for i in 0..4 {
        // each worker gets its own OS thread (~MBs of stack)
        handles.push(thread::spawn(move || i * i));
    }
    // join blocks the main thread until each finishes
    let results: Vec<i32> = handles
        .into_iter()
        .map(|h| h.join().unwrap())
        .collect();
    println!("{:?}", results); // [0, 1, 4, 9]
}

#[tokio::main]                       // sets up the async runtime
async fn main() {
    let mut handles = Vec::new();
    for i in 0..4 {
        // each worker is a lightweight task (~hundreds of bytes)
        handles.push(tokio::spawn(async move { i * i }));
    }
    // .await yields instead of blocking the thread
    let mut results = Vec::new();
    for h in handles {
        results.push(h.await.unwrap());
    }
    println!("{:?}", results); // [0, 1, 4, 9]
}

// Poll::Pending vs Poll::Ready

What async really is (the Future trait)

We keep saying "the executor polls a task", but what is the task? A future is a value that stands for a computation that has not finished yet: a job you can hold in a variable, pass around, and repeatedly ask "are you done?". It is the description of the work, not a thread busy doing it. In Rust every async fn and async block compiles into exactly such a value: a type that implements the Future trait.

That trait is tiny. It has one method, poll, which returns Poll::Ready(value) when the work is finished or Poll::Pending when it is not. And futures are lazy: constructing one runs none of its code. Until something calls poll, a future is inert data, which is why an async fn you never await simply does nothing.

// A plain block: `return` exits the whole function.
fn example() -> i32 {
    let x = {
        return 5; // returns from example() immediately
    };
    // unreachable: the block diverges, so x has the never type `!`
}

// An async block: `return` resolves the block's Future.
async fn example() -> i32 {
    let x = async {
        return 5; // sets this Future's output to 5, does NOT exit example()
    };

    // x is a Future<Output = i32>. It has run no code yet (lazy).
    x.await // driving it here is what finally produces 5
}

And that machine is not a metaphor: it is quite literally the enum the compiler generates for you.

// You write this:
async fn handle(mut sock: TcpStream) -> usize {
    let n = sock.read(&mut buf).await;   // pause point #1
    store(&buf[..n]).await;              // pause point #2
    n                                    // final value
}

// The compiler rewrites it into roughly this state machine.
// Each .await becomes a state the future can be "parked" in.
enum Handle {
    Start   { sock: TcpStream },              // not polled yet
    Reading { fut: ReadFuture },              // parked at .await #1
    Storing { fut: StoreFuture, n: usize },   // parked at .await #2
    Done,
}

// poll() looks at the current state, tries to drive the inner
// future, and either advances to the next state, returns
// Poll::Pending (saving where it stopped), or Poll::Ready(n).

At the bottom of every such chain sits a leaf future, one that actually talks to the outside world (a socket, a timer) instead of awaiting another future. This is where Pending and the Waker come from. Here is one written by hand so the contract is visible:

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};
use std::time::Instant;

// A hand-written future: an async fn compiles to something like this.
struct Delay { deadline: Instant }

impl Future for Delay {
    type Output = ();

    // The executor calls poll(). We either finish or ask to be polled later.
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
        if Instant::now() >= self.deadline {
            Poll::Ready(())                 // done: hand back the value
        } else {
            // Not ready. Hand the executor a Waker so it can re-poll us
            // once the timer fires, instead of busy-looping.
            register_timer(self.deadline, cx.waker().clone());
            Poll::Pending
        }
    }
}

Notice the Waker. When a leaf returns Pending it first stashes the waker it was handed in the Context. The waker is the future's way of saying "call poll on me again when there is news". The runtime keeps it, and once the resource is ready it invokes wake() to put the task back on a run queue. No busy-waiting, and no thread parked per future.

Here is that interface in action. Follow one future that is waiting to read from a TCP socket, and watch how the reactor uses epoll to keep the thread free instead of blocking it inside a read:

One question the diagram leaves open: who creates that epoll instance, and when? You never call epoll_create yourself. It is created once, when the runtime starts up, by its I/O driver (the reactor). In Rust that is exactly what enable_io(), implied by #[tokio::main], switches on; the one instance is then shared by every task, and individual descriptors are registered into it lazily the first time each resource is polled. This is not a Rust quirk: Node's libuv, Python's asyncio selector and Go's netpoller each create theirs the same way, at event-loop start-up. The Tokio section below shows the exact call; first, how the same idea looks in other languages.

Futures are not a Rust idea

The concept goes back to the 1970s (Baker and Hewitt named "futures", Friedman and Wise "promises") and almost every mainstream language ships one today: JavaScript's Promise, Python's coroutine, C#'s Task, Java's CompletableFuture. What changes from language to language is two things: whether the async value is lazy (does nothing until driven) or eager (already running), and whether the runtime is built into the language or something you choose. Rust is the unusual one on both counts.

Only two independent questions separate one language's async value from another's, so every language lands in one of four boxes:

That is the whole "zoom out": once two async values are both lazy, they run identically underneath. Each is created inert, each hands out a one-shot resume handle (Rust's Waker, Python's done-callback, Kotlin's Continuation, C++20's coroutine_handle) that means "call me to resume this", and each is driven by a loop that sleeps on the OS async interface rather than busy-waiting. The eager designs differ in one respect only: the value starts the moment it is created. The table below turns every one of these traits into a column, and the Lazy or eager row draws it as a small timeline so you can see the difference at a glance.

Comparison table: futures across languages

This is the per-language table: what the async value is in each language and how it behaves, lazy or eager, its resume handle, whether a runtime is built in, and the syntax. It stops at the language boundary. For how a concrete runtime actually schedules those futures (Tokio vs smol vs glommio vs an event loop), jump to Comparison table: concurrency runtimes.

Pick languages to compare their model and syntax side by side. The first snippet runs the same task everywhere: an async double(x) returning x * 2, called on 10 and 20 concurrently and summed to 60. The second shows the async-block structure from above (a return inside an inner async value) in each language, so you can see how the same idea is spelled and whether it is lazy or eager.

use tokio::join;

// async fn returns a Future: lazy, does nothing until driven
async fn double(x: i32) -> i32 {
    x * 2
}

#[tokio::main]
async fn main() {
    // join! polls both futures concurrently, then awaits them
    let (a, b) = join!(double(10), double(20));
    println!("{}", a + b); // 60
}

// calling double() starts the Promise immediately (eager)
async function double(x) {
  return x * 2;
}

// Promise.all awaits both concurrently
const [a, b] = await Promise.all([double(10), double(20)]);
console.log(a + b); // 60

import asyncio

# calling double() builds a coroutine: lazy, awaited later
async def double(x: int) -> int:
    return x * 2

async def main() -> None:
    # gather schedules and awaits both concurrently
    a, b = await asyncio.gather(double(10), double(20))
    print(a + b)  # 60

asyncio.run(main())

// no async/await: a goroutine + channel stand in for a future
func double(x int, out chan<- int) {
    out <- x * 2 // starts running immediately (eager)
}

func main() {
    out := make(chan int, 2)
    go double(10, out)
    go double(20, out)
    fmt.Println(<-out + <-out) // 60
}

async fn example() -> i32 {
    let x = async {
        return 5; // resolves THIS Future, not example()
    };

    // x is a Future<Output = i32> that has run nothing yet (lazy)
    x.await // awaiting drives it and yields 5
}

async function example() {
  const x = (async () => {
    return 5; // resolves THIS Promise, not example()
  })();

  // x is a Promise, but note: it already started running (eager)
  return await x; // await yields 5
}

async def example() -> int:
    async def inner() -> int:
        return 5  # resolves THIS coroutine, not example()

    x = inner()      # a coroutine object; runs nothing yet (lazy)
    return await x   # awaiting drives it and yields 5

func example() int {
    ch := make(chan int, 1)
    go func() {
        ch <- 5
        return // returns from the goroutine, not example()
    }()

    // the channel receive is the "await": it produces 5
    return <-ch
}

// tokio::spawn(async move { ... })

Async & Concurrency Runtimes

A future does nothing on its own, and every language just met has the same problem. Something has to poll those tasks: a concurrency runtime that schedules async work, manages I/O multiplexing, and distributes it across cores. Some languages bake one in (Go, Erlang); others let you choose (Rust, Python). The differences matter when you're building servers, embedded systems, or anything that waits on I/O.

How the same async block gets scheduled

The cards above list which runtimes exist per language; this shows how they actually run your tasks. Take one identical async task and hand it to different runtimes: almost every one falls into one of four scheduling shapes. That shape, not the syntax, is what decides whether a task can hop threads, whether it can be interrupted, and whether it must be Send.

// same task, different runtimes

Same Pattern, Different Runtimes

You have seen one runtime from the inside; now compare several from the outside. Pick up to four and put them head to head: first the same spawn & collect task as above (4 workers computing i * i) to see the bare syntax, then a real-world outbox-relay worker: a listener watches for new work (e.g. database LISTEN/NOTIFY), signals a wakeup, and N relay workers pick it up and process it concurrently. Each snippet has a short note on what makes that runtime distinctive.

Comparison table: concurrency runtimes

This is the per-runtime table: given those futures, how does each concrete runtime schedule the work and which primitives does it hand you (scheduler, I/O backend, spawn bounds, wakeup, fan-out, parallelism)? It deliberately skips "what a future is", that is the language-level story in Comparison table: futures across languages. Think of it as the same async value, viewed one layer lower.

import asyncio

async def worker(i: int) -> int:
    return i * i                       # a trivial async task

async def main() -> None:
    # create_task schedules them; gather awaits all, in order
    tasks = [asyncio.create_task(worker(i)) for i in range(4)]
    results = await asyncio.gather(*tasks)
    print(results)                     # [0, 1, 4, 9]

asyncio.run(main())                    # starts + drives the loop

#[tokio::main]                       // sets up the async runtime
async fn main() {
    let mut handles = Vec::new();
    for i in 0..4 {
        // each worker is a lightweight task (~hundreds of bytes)
        handles.push(tokio::spawn(async move { i * i }));
    }
    // .await yields instead of blocking the thread
    let mut results = Vec::new();
    for h in handles {
        results.push(h.await.unwrap());
    }
    println!("{:?}", results); // [0, 1, 4, 9]
}

package main

import (
	"fmt"
	"sync"
)

func main() {
	results := make([]int, 4)
	var wg sync.WaitGroup
	for i := 0; i < 4; i++ {
		wg.Add(1)
		go func(i int) { // no async keyword, just "go"
			defer wg.Done()
			results[i] = i * i
		}(i)
	}
	wg.Wait()            // join all goroutines
	fmt.Println(results) // [0 1 4 9]
}

fn main() {
    // block_on drives the futures; no #[main] macro needed
    smol::block_on(async {
        let mut handles = Vec::new();
        for i in 0..4 {
            handles.push(smol::spawn(async move { i * i }));
        }
        let mut results = Vec::new();
        for h in handles {
            results.push(h.await);   // smol tasks return the value directly
        }
        println!("{:?}", results);   // [0, 1, 4, 9]
    });
}

import asyncio

class OutboxRelayWorker:
    def __init__(self, worker_count: int = 4):
        self._worker_count = worker_count

    async def _listen_loop(self, wakeup: asyncio.Event) -> None:
        while True:
            await asyncio.sleep(1)      # stand-in for pg LISTEN/NOTIFY
            wakeup.set()                # wake every waiter at once

    async def _relay_loop(self, wakeup: asyncio.Event) -> None:
        while True:
            await wakeup.wait()         # suspend until signalled
            wakeup.clear()              # must reset the flag manually
            print("relaying outbox batch...")

    async def run(self) -> None:
        wakeup = asyncio.Event()
        # create_task schedules coroutines on the single event loop
        tasks = [
            asyncio.create_task(self._listen_loop(wakeup), name="listen"),
            *[
                asyncio.create_task(self._relay_loop(wakeup), name=f"relay-{i}")
                for i in range(self._worker_count)
            ],
        ]
        await asyncio.gather(*tasks)    # join all tasks

asyncio.run(OutboxRelayWorker().run())

use tokio::sync::Notify;
use std::sync::Arc;

// Notify is shared via Arc because tasks run on different threads
async fn listen_loop(wakeup: Arc<Notify>) {
    loop {
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
        wakeup.notify_waiters();        // wake all current waiters
    }
}

async fn relay_loop(wakeup: Arc<Notify>) {
    loop {
        wakeup.notified().await;        // no manual clear needed
        println!("relaying outbox batch...");
    }
}

#[tokio::main]
async fn main() {
    let wakeup = Arc::new(Notify::new());
    let mut set = tokio::task::JoinSet::new();

    set.spawn(listen_loop(wakeup.clone()));    // onto the thread pool
    for _ in 0..4 {
        set.spawn(relay_loop(wakeup.clone())); // Send + 'static required
    }
    while set.join_next().await.is_some() {}   // join the whole set
}

package main

import (
	"fmt"
	"sync"
	"time"
)

type OutboxRelayWorker struct {
	workerCount int
}

func (w *OutboxRelayWorker) listenLoop(wakeup chan struct{}) {
	for {
		time.Sleep(1 * time.Second)
		select {
		case wakeup <- struct{}{}: // non-blocking send
		default:                   // drop if no worker is ready
		}
	}
}

func (w *OutboxRelayWorker) relayLoop(wakeup chan struct{}, wg *sync.WaitGroup) {
	defer wg.Done()
	for range wakeup { // ranges until the channel closes
		fmt.Println("relaying outbox batch...")
	}
}

func (w *OutboxRelayWorker) Run() {
	wakeup := make(chan struct{}, 1) // the channel *is* the signal
	var wg sync.WaitGroup

	go w.listenLoop(wakeup) // no async keyword, just "go"

	for i := 0; i < w.workerCount; i++ {
		wg.Add(1)
		go w.relayLoop(wakeup, &wg)
	}
	wg.Wait()
}

func main() {
	(&OutboxRelayWorker{workerCount: 4}).Run()
}

use event_listener::Event;
use std::sync::Arc;

// event_listener::Event is smol's stand-in for Tokio's Notify
async fn listen_loop(wakeup: Arc<Event>) {
    loop {
        smol::Timer::after(std::time::Duration::from_secs(1)).await;
        wakeup.notify(usize::MAX);      // wake all listeners
    }
}

async fn relay_loop(wakeup: Arc<Event>) {
    loop {
        wakeup.listen().await;          // register + wait for a signal
        println!("relaying outbox batch...");
    }
}

fn main() {
    let wakeup = Arc::new(Event::new());
    // no runtime macro: build a multi-thread executor by hand
    let ex = Arc::new(smol::Executor::new());
    smol::block_on(ex.run(async {
        ex.spawn(listen_loop(wakeup.clone())).detach();
        for _ in 0..4 {
            ex.spawn(relay_loop(wakeup.clone())).detach();
        }
        futures_lite::future::pending::<()>().await;
    }));
}

These snippets are illustrative: each async runtime is an external crate, so it needs the matching dependency in Cargo.toml (tokio, smol, glommio). Only the std::thread version is self-contained; glommio additionally requires Linux io_uring, so it will not run in the standard Rust playground.

// answer them all to reach Poll::Ready

Quiz: Rust futures

A self-check on everything above. The questions run from medium to hard across the async model, the state machine, executors, Pin / Unpin, the Waker contract, and how Rust differs from Go, JavaScript, Python, C# and Kotlin. Nothing is saved, so run it as often as you like. Answer with a click, or with the keyboard (1-4 / A-D to answer, arrows to move).

impl Future for You {
    type Output = Mastery;
    fn poll(self, cx) -> Poll<Output> {
        // answer them all to reach Poll::Ready
    }
}