Rust Tokio Async Non-Blocking & Thread Memory Safety Invariants

Prohibits synchronous blocking calls (std::thread::sleep, blocking file I/O) and cross-await std::sync::MutexGuard retention inside Tokio async tasks.

Authors:Tokio Project Working Group, AgentRules Systems Group

Version:v1.0.0

Last Ratified:2026-03-25

Linked Rule:rust-axum-tokio

RFC-2119 Invariant Mandates

The keywords “MUST”, “MUST NOT”, and “SHOULD” in this document are to be interpreted as described in BCP 14 / RFC 2119.

MUST NOTClause 1

Async functions ('async fn') MUST NOT invoke std::thread::sleep or synchronous filesystem/socket I/O.

Engineering Rationale:std::thread::sleep blocks the OS thread in Tokio's multi-threaded worker pool, starving hundreds of co-scheduled tasks.

Failure Blast Radius:Thread pool starvation, latency explosions, and deadlock.

MUST NOTClause 2

Async tasks MUST NOT hold an std::sync::MutexGuard across an .await suspension point.

Engineering Rationale:Holding a non-async mutex across await points can cause deadlocks if the task is rescheduled onto another worker thread.

Failure Blast Radius:Send trait compilation errors or runtime deadlocks.

MUSTClause 3

CPU-heavy computation or legacy blocking I/O MUST be offloaded using tokio::task::spawn_blocking.

Engineering Rationale:spawn_blocking runs tasks on a dedicated thread pool designed for blocking operations.

Failure Blast Radius:Preserves Tokio reactor loop low-latency responsiveness.

Complete RFC Specification Document

IETF Formal Markdown Format

# RFC-009: Rust Tokio Non-Blocking Invariants

```rust
// COMPLIANT:
tokio::time::sleep(Duration::from_millis(100)).await;

// FORBIDDEN:
std::thread::sleep(Duration::from_millis(100)); // Freezes worker OS thread!
```

Community Consensus Rating

Do these behavioral constraints represent the highest engineering standard for your team?

99% Consensus