tokio-rust

Applies Tokio async runtime conventions, patterns, and anti-patterns to Rust code.

2|Updated May 16, 2026
One-click install
npx skills add https://github.com/avbel/ai-skills --skill tokio-rust-avbel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tokio-rust
Source: https://github.com/avbel/ai-skills/tree/main/skills/tokio-rust
Command: npx skills add https://github.com/avbel/ai-skills --skill tokio-rust-avbel

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing correct async Rust with Tokio requires knowing which synchronization primitive, channel type, and spawning strategy fits each scenario, and mistakes like blocking the runtime or holding a std::sync::Mutex across .await cause deadlocks and data loss that are hard to debug. ## Core Features & Use Cases - Pattern and Anti-Pattern Guidance: Enforces bounded channels, spawn_blocking for blocking work, JoinSet for task groups, and CancellationToken for shutdown while flagging common mistakes like unbounded channels and non-cancel-safe futures in select!. - Module and Sync Reference: Provides a decision table for mpsc, oneshot, broadcast, and watch channels plus comparisons of std::sync::Mutex vs tokio::sync::Mutex, RwLock, Semaphore, Notify, and Barrier. - Use Case: When building a TCP server that must shut down cleanly, the Skill guides you to combine a watch channel or CancellationToken with a biased select! loop so shutdown signals are checked before new work. ## Quick Start Review my Tokio-based Rust code and fix any async anti-patterns such as blocking calls or unbounded channels.

Frequently Asked Questions about tokio-rust

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose between Tokio channel types in Rust?▼

Use mpsc::channel(cap) for work queues with backpressure, oneshot for single request-response, broadcast when all subscribers need every message, and watch when only the latest value matters such as config or shutdown signals. Prefer bounded channels over unbounded to prevent OOM.

When should I use std::sync::Mutex vs tokio::sync::Mutex?▼

Use std::sync::Mutex when the critical section contains no .await calls since it is significantly faster with no allocation. Use tokio::sync::Mutex only when the lock must be held across an .await point, because holding a std mutex across await can deadlock the runtime.

Why does my Tokio task block the entire runtime?▼

Blocking happens when synchronous calls like std::thread::sleep, std::fs::read, or CPU-heavy loops run inside async tasks, starving other tasks on that worker thread. Move blocking work into tokio::task::spawn_blocking or use block_in_place on multi-thread runtimes.

Which futures are cancel-safe in tokio::select!?▼

Cancel-safe operations include mpsc::recv, broadcast::recv, watch::changed, TcpListener::accept, and StreamExt::next. Operations like read_exact, read_to_end, and io::copy lose partial progress on cancellation, so wrap them in tokio::spawn and select on the JoinHandle instead.

When should I avoid using Tokio in Rust?▼

Avoid Tokio for CPU-bound computation (use rayon), simple CLI tools and batch processing (use plain sync Rust), embedded targets (use embassy), and library code that should stay runtime-agnostic. Tokio only pays off when you have concurrent async I/O like networking or timers.