Channels in Rust: The Art of Concurrency
summary
Explains how Rust channels actually behave: std gives bounded vs unbounded where an unbounded sender can exhaust memory and bounded blocks the sender after a buffer (eg buffer of 10 then block on 11); sending transfers ownership so ownership moves over channels and you can clone senders but not receivers (MPSC: clone senders only). Compares std, crossbeam (claims atomics-based), tokio async channels, one-shot, watch, broadcast vs sync broadcast with backpressure and cancellation tokens used in kube-rs.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 2:10Mutexes vs channels in Rust
- 3:34Ownership transfer in channels
- 4:18Unbounded vs bounded channels
- 5:21MPSC channels sync
- 6:45Try send and error handling
- 7:48Crossbeam channels
- 9:32Async channels with Tokio
- 11:58One-shot channels
- 13:46Fan-in pattern
- 15:56Broadcast channels
- 18:01Sync broadcast limits
- 20:52Tokio select for channels
- 22:38Watch channels
- 24:47Graceful shutdown
- 26:11Back pressure strategies
- 28:37Cancellation tokens
- 30:22Channel types summary
- 30:42Open source contributions
related talks
47mChannels - An alternative to callbacks and futures
01h 04mcore.async: Concurrency without Callbacks
39mRust Atomics in the Wild: Memory Ordering Design Patterns [...]
45mRust: safe and concurrent. But how does it do it?
41mCap'n Proto and Rust: Type Systems for Sharing
01h 05mKeynote - Rust: confident, productive systems programming
02h 02mCloud Native Rust Workshop: Let's go parallel with Rust
34mMove fast and don't break things: High-performance networking in Rust