Elevator Pitch

• Cancellation in async Rust is both powerful and perilous, requiring developers to deeply understand and mitigate the risks of silent future cancellation to ensure robust, correct systems.

Key Takeaways

• Futures in Rust are passive and can be cancelled simply by dropping them, making cancellation easy but also introducing subtle bugs due to non-local reasoning.
• The concepts of cancel safety (local property) and cancel correctness (global system property) help frame when cancellations are harmless versus when they introduce serious bugs.
• Practical strategies—such as redesigning APIs to be cancel-safe, careful use of select loops, and leveraging tasks—can reduce, but not eliminate, the risks of cancellation bugs in async Rust.

Most Memorable Aspects

• Real-world bugs at Oxide were traced back to subtle cancellation issues, like leaving shared state in an invalid state after an async mutex lock was cancelled.
• Certain async patterns, e.g., Tokio’s select! macro or try_join, can silently cancel futures, leading to missed work or lost data.
• The author argues that cancellation is "the least Rusty part of Rust," clashing with Rust’s usual guarantees of local reasoning and correctness.

Direct Quotes

• “If you can take away one thing from this post, it would be that futures are passive, and completely inert until awaited or polled.”
• “Cancel safety is a local property of an individual future...what actually matters is...cancel correctness, a global property of system correctness in the face of cancellations.”
• “The promise of Rust is that you don’t need to do this kind of non-local reasoning...Future cancellations fly directly in the face of that, and I think they’re probably the least Rusty part of Rust.”