It also covers the async-fn-in-traits Send problem — why async fn in traits does not give
Send futures by default and how to work around it.
Out of scope: HTTP service structure (routing, extractors, middleware) is owned by
rust-web-backend; sync-only ownership and borrowing questions belong to rust-core-language.
Rust Async & Concurrency
Agent Workflow (MANDATORY)
Before writing async code, spawn in parallel:
- fuse-ai-pilot:explore-codebase — find the existing runtime, channel, and lock patterns already in use
- fuse-ai-pilot:research-expert — verify current tokio/crate APIs via Context7/Exa (async APIs churn)
- mcp__context7__query-docs — pull exact signatures for the primitives you touch
After writing, run fuse-ai-pilot:sniper.
Runtime Landscape
| Runtime |
Reality |
| tokio |
The de-facto standard. Almost every async crate (axum, sqlx, reqwest, tonic) targets it. Default choice. |
| async-std |
Niche, effectively in maintenance mode. Do not pick for new work. |
| smol |
Niche, small/embeddable. Only for constrained or embedded contexts. |
Default to tokio unless a hard constraint says otherwise.
Critical Rules
std::sync::Mutex first — it is faster. Reach for tokio::sync::Mutex ONLY when the guard must be held across an .await. Otherwise scope the guard so its destructor runs before the await.
Arc<Mutex<T>> is not the default — analyze contention first. Read-dominated → RwLock; a simple counter → atomics; work that is itself async → a task + message passing.
- Never drop a
JoinHandle you care about — a dropped tokio::spawn handle silently swallows the task's panic/error. .await it, or use JoinSet/tracing to surface failures.
spawn_blocking for heavy sync work — CPU-bound loops or blocking I/O (std file, blocking DB driver) starve the runtime if run on an async worker. Offload them.
Send across .await — everything held across an await point must be Send for tokio::spawn. A std::sync::MutexGuard is NOT Send; holding one across an await is a compile error (and async-mutex guards that are Send deadlock instead).
Reference Guide
Concepts
| Topic |
Reference |
When to Consult |
| Runtime & tasks |
runtime-and-tasks.md |
spawn, JoinHandle, JoinSet, spawn_blocking, 'static bound |
| Shared state |
shared-state.md |
Choosing Mutex vs RwLock vs atomics vs actor task |
| Channels |
channels.md |
Picking mpsc / oneshot / broadcast / watch |
| Async traits |
async-traits.md |
async fn in traits + the Send-bound problem |
Templates
| Template |
When to Use |
| task-patterns.md |
Concurrent tasks, JoinSet, actor pattern, spawn_blocking |
| graceful-shutdown.md |
Cancellation, shutdown signal, draining tasks |
Quick Reference
Scope the guard, don't hold it across .await
// GOOD: lock released before the await
{
let mut db = state.lock().unwrap();
db.insert(key, value);
} // guard dropped here
do_async_work().await;
→ See shared-state.md
Pick the channel by shape
// one value back to a caller → oneshot
// many producers, one consumer → mpsc
// fan-out same value to all → broadcast
// latest-value-only state → watch
→ See channels.md
Best Practices
DO
- Measure contention before choosing a lock; prefer the cheapest primitive that fits.
- Surface task failures:
.await handles, or collect them with JoinSet.
- Move heavy synchronous work to
spawn_blocking.
DON'T
- Reach for
tokio::sync::Mutex by reflex — it wraps a sync mutex internally and rarely helps throughput.
- Fire-and-forget a
tokio::spawn whose result or panic matters.
- Assume
async fn in traits gives you Send futures — it does not (see async-traits.md).
Sources (verified)
- tokio.rs/tokio/tutorial — shared-state, spawning, channels (fetched 2026-07-05)
- rust-lang.github.io/async-fundamentals-initiative/roadmap.html — AFIT status
- crates.io — tokio 1.52.3 (current at fetch)
1---2name: rust-async-concurrency3description: Use when writing async Rust — spawning tasks, sharing state across tasks/threads, choosing channels vs mutexes, or hitting Send-bound errors with async traits. Not for HTTP service structure (rust-web-backend) or sync-only ownership (rust-core-language).4---56<objective>7This skill covers writing and reviewing async Rust code on the tokio runtime: spawning and8supervising tasks (spawn, JoinHandle, JoinSet, spawn_blocking), choosing shared-state9primitives (Mutex, RwLock, atomics) versus message passing, and picking the right channel10shape (mpsc, oneshot, broadcast, watch).1112It also covers the async-fn-in-traits Send problem — why `async fn` in traits does not give13Send futures by default and how to work around it.1415Out of scope: HTTP service structure (routing, extractors, middleware) is owned by16rust-web-backend; sync-only ownership and borrowing questions belong to rust-core-language.17</objective>1819# Rust Async & Concurrency2021## Agent Workflow (MANDATORY)2223Before writing async code, spawn in parallel:24251. **fuse-ai-pilot:explore-codebase** — find the existing runtime, channel, and lock patterns already in use262. **fuse-ai-pilot:research-expert** — verify current tokio/crate APIs via Context7/Exa (async APIs churn)273. **mcp__context7__query-docs** — pull exact signatures for the primitives you touch2829After writing, run **fuse-ai-pilot:sniper**.3031---3233## Runtime Landscape3435| Runtime | Reality |36|---------|---------|37| **tokio** | The de-facto standard. Almost every async crate (axum, sqlx, reqwest, tonic) targets it. Default choice. |38| **async-std** | Niche, effectively in maintenance mode. Do not pick for new work. |39| **smol** | Niche, small/embeddable. Only for constrained or embedded contexts. |4041Default to tokio unless a hard constraint says otherwise.4243---4445## Critical Rules46471. **`std::sync::Mutex` first** — it is faster. Reach for `tokio::sync::Mutex` ONLY when the guard must be held across an `.await`. Otherwise scope the guard so its destructor runs before the await.482. **`Arc<Mutex<T>>` is not the default** — analyze contention first. Read-dominated → `RwLock`; a simple counter → atomics; work that is itself async → a task + message passing.493. **Never drop a `JoinHandle` you care about** — a dropped `tokio::spawn` handle silently swallows the task's panic/error. `.await` it, or use `JoinSet`/`tracing` to surface failures.504. **`spawn_blocking` for heavy sync work** — CPU-bound loops or blocking I/O (std file, blocking DB driver) starve the runtime if run on an async worker. Offload them.515. **`Send` across `.await`** — everything held across an await point must be `Send` for `tokio::spawn`. A `std::sync::MutexGuard` is NOT `Send`; holding one across an await is a compile error (and async-mutex guards that *are* `Send` deadlock instead).5253---5455## Reference Guide5657### Concepts5859| Topic | Reference | When to Consult |60|-------|-----------|-----------------|61| **Runtime & tasks** | [runtime-and-tasks.md](references/runtime-and-tasks.md) | spawn, JoinHandle, JoinSet, spawn_blocking, `'static` bound |62| **Shared state** | [shared-state.md](references/shared-state.md) | Choosing Mutex vs RwLock vs atomics vs actor task |63| **Channels** | [channels.md](references/channels.md) | Picking mpsc / oneshot / broadcast / watch |64| **Async traits** | [async-traits.md](references/async-traits.md) | `async fn` in traits + the Send-bound problem |6566### Templates6768| Template | When to Use |69|----------|-------------|70| [task-patterns.md](references/templates/task-patterns.md) | Concurrent tasks, JoinSet, actor pattern, spawn_blocking |71| [graceful-shutdown.md](references/templates/graceful-shutdown.md) | Cancellation, shutdown signal, draining tasks |7273---7475## Quick Reference7677### Scope the guard, don't hold it across `.await`7879```rust80// GOOD: lock released before the await81{82 let mut db = state.lock().unwrap();83 db.insert(key, value);84} // guard dropped here85do_async_work().await;86```8788→ See [shared-state.md](references/shared-state.md)8990### Pick the channel by shape9192```rust93// one value back to a caller → oneshot94// many producers, one consumer → mpsc95// fan-out same value to all → broadcast96// latest-value-only state → watch97```9899→ See [channels.md](references/channels.md)100101---102103## Best Practices104105### DO106- Measure contention before choosing a lock; prefer the cheapest primitive that fits.107- Surface task failures: `.await` handles, or collect them with `JoinSet`.108- Move heavy synchronous work to `spawn_blocking`.109110### DON'T111- Reach for `tokio::sync::Mutex` by reflex — it wraps a sync mutex internally and rarely helps throughput.112- Fire-and-forget a `tokio::spawn` whose result or panic matters.113- Assume `async fn` in traits gives you `Send` futures — it does not (see async-traits.md).114115---116117## Sources (verified)118119- tokio.rs/tokio/tutorial — shared-state, spawning, channels (fetched 2026-07-05)120- rust-lang.github.io/async-fundamentals-initiative/roadmap.html — AFIT status121- crates.io — tokio 1.52.3 (current at fetch)