Tokio — Async Runtime for Reliable Rust Applications

What Tokio Does

• Multi-threaded scheduler — work-stealing for parallel async tasks
• Async I/O — TCP, UDP, Unix sockets, named pipes
• Timers — sleep, interval, timeout
• Channels — mpsc, oneshot, broadcast, watch
• Sync primitives — Mutex, RwLock, Semaphore, Notify (async-aware)
• Task spawning — lightweight green threads
• Runtime — configurable (multi-thread or current-thread)
• Tracing — integrated with tokio-console for debugging

Architecture

Work-stealing scheduler: multiple OS threads each maintain a local task queue. When idle, a thread steals tasks from others. Each task is a Future that the runtime polls. I/O is backed by epoll (Linux), kqueue (macOS), or IOCP (Windows) via the mio crate.

Comparison

FAQ

Q: When to use Tokio? A: Any Rust project that needs async I/O — web server, gRPC, database clients, concurrent requests in CLI tools.

Q: Compared to async-std? A: Tokio has the largest ecosystem, the most active maintenance, and the best performance. async-std more closely mirrors the std API but has a smaller community.

Sources

• Docs: https://tokio.rs
• GitHub: https://github.com/tokio-rs/tokio
• License: MIT