Tokio is Rust's leading async runtime, powering high-performance networked applications. Master the select! macro, join!, JoinSet, CancellationToken, broadcast channels, and watch channels — the essential vocabulary for concurrent Rust development with Tokio.
0 / 5 completed
1 / 5
A Rust developer uses tokio::select! { val = future_a => {...}, _ = future_b => {...} }. What does select! do with the non-selected future?
In Tokio's select!, when one branch completes, all other futures are dropped. Dropping a future in Rust cancels it — any pending async work (network calls, timers) is abandoned. This is a critical property to understand: futures used in select! must be cancellation-safe, or data may be lost when they're dropped mid-operation.
2 / 5
A developer uses tokio::join!(fetch_a(), fetch_b(), fetch_c()). How does join! differ from select!?
tokio::join! polls all provided futures concurrently and waits for all of them to complete, returning a tuple of all results. select! returns as soon as any one branch completes, dropping the rest. Use join! when you need all results; use select! for racing or handling whichever finishes first.
3 / 5
A server uses tokio::task::JoinSet to manage multiple spawned tasks. What does join_set.join_next().await return?
JoinSet::join_next() awaits the next task to complete across all tasks in the set, regardless of spawn order. It returns Some(Result) or None when the set is empty. This is ideal for processing results as they arrive — like a fan-out/fan-in pattern where results are handled as each task finishes.
4 / 5
A Tokio application uses CancellationToken from the tokio_util crate. What is its primary use case?
CancellationToken is a shareable, cloneable token that can be used to cooperatively cancel multiple related tasks. Tasks check token.cancelled().await or use token.run_until_cancelled() to yield when cancellation is requested. When token.cancel() is called, all tasks sharing that token (or child tokens) receive the signal — enabling graceful shutdown patterns.
5 / 5
A Tokio service uses a broadcast::channel for fan-out messaging. What happens to a slow receiver that falls behind the sender in a broadcast channel?
Tokio's broadcast::channel has a fixed-capacity ring buffer. If a receiver falls behind and the buffer wraps around, the oldest messages for that receiver are overwritten. When the slow receiver calls recv() next, it receives Err(RecvError::Lagged(n)) indicating how many messages were skipped. This prevents slow receivers from blocking the sender.