Message Passing with mpsc

std::sync::mpsc::channel() returns a (Sender<T>, Receiver<T>) pair connected by a queue, and the type signatures already encode the design. The channel is multi-producer, single-consumer: Sender implements Clone, so you can hand copies to any number of threads; Receiver implements neither Clone nor Sync, so exactly one thread may drain it:

use std::sync::mpsc;
use std::thread;

let (tx, rx) = mpsc::channel::<i32>();       // T is inferred from use

let tx2 = tx.clone();                         // a second producer
thread::spawn(move || { for n in 0..3 { tx.send(n).unwrap(); } });
thread::spawn(move || { for n in 10..13 { tx2.send(n).unwrap(); } });

let mut got: Vec<i32> = rx.iter().collect();  // blocks until ALL senders drop
println!("{got:?}");

The single-consumer constraint is not a missing feature — it is what lets the implementation stay lock-cheap on the receiving end, and it matches the ownership model: moving values out of a shared queue requires unique access, which &Receiver gives only to its one owner. If you need multiple consumers, fan-in to one receiver, or put a Mutex around a shared receiver (rare), or restructure with one channel per consumer.

Sending moves the value. send(self, t: T) takes ownership, so after tx.send(name) the producer cannot use name anymore — channels are ownership transfer over time, the message-passing counterpart of the move closures from Moving Data into Threads. Each message is enqueued by moving it into the channel's internal buffer; each receive dequeues by moving it back out. Nothing is borrowed, nothing is shared, and that is precisely why channels need no Arc. A producer that wants to reuse its data sends a clone (tx.send(data.clone())) or sends an Arc<T> so every consumer shares one copy — the same move/clone/Arc ladder, now per message instead of per thread.

Because the values move, the type system keeps the pipeline honest end to end: a channel of String cannot leak a borrowed slice across threads, and a channel's T must be Send to cross the thread boundary at all (a channel of Rc<str> won't compile — the same !Send wall that guards spawn). When the payload itself is a handle — a Sender — you can even build trees of channels: a worker that receives "reply-to" senders to answer on, which is how request/response protocols get layered on mpsc without any shared state.

send also returns Result<(), SendError<T>>: it fails only if every Receiver has been dropped. The failed send hands the value back inside the error (nothing is silently lost), and a worker that logs and drops a SendError is declaring "this result is moot because nobody's listening." Notice the asymmetry with receiving — producers can be many, so a producer's failure is detected per-send; the consumer's end-of-stream is detected once, when the last sender disappears.

Interview framing: be able to state the ownership story cold: channel() creates a queue; Sender: Clone gives multi-producer; Receiver is uniquely owned because dequeuing moves values out; send moves the value in and fails only when the receiver is gone. Follow-ups usually probe why std channels are single-consumer — tie it to &mut uniqueness and queue-dequeue semantics.

Receiver::recv(&self) blocks the calling thread until a message arrives or every Sender has been dropped, returning Result<T, RecvError>:

loop {
    match rx.recv() {
        Ok(msg) => handle(msg),
        Err(mpsc::RecvError) => break,     // channel closed: all senders gone
    }
}

Ok(v) delivers a value (moved out of the queue); Err(RecvError) is the channel's EOF — not an error condition but a signal that no more messages can ever arrive, because disconnection is defined by sender counts, not by an explicit "close" call. There is no close() method: the channel shuts itself down when the last Sender drops, including clones moved into worker threads. That is why the producer loop above works as a program: when both producer threads end, their tx clones drop, the count hits zero, and rx.iter() terminates.

The iterator form is the ergonomic wrapper over exactly that contract:

for msg in rx { handle(msg); }      // equivalent to: while let Ok(m) = rx.recv()

When you cannot afford to block, try_recv(&self) returns immediately: Ok(v), Err(Empty) if the queue is momentarily empty (retry later), or Err(Disconnected) when the channel is finished — the three-state answer that a poll loop or game tick needs. recv_timeout(Duration) (stable since 1.52 for mpsc) sits between the two, returning Err(RecvTimeoutError::Timeout | Disconnected).

Two failure modes to have ready. First, a leaked sender hangs the consumer forever: if any Sender clone — including one captured by a detached thread or stored in a struct — is still alive, recv and iter() block past the point where "logical" work ended. The fix is ownership hygiene: drop senders when the producing phase ends (scoped spawn makes this automatic, since captures drop when the thread finishes). Second, messages outlive their sender: dropping the Sender does not flush or discard queued items — the receiver drains what is buffered, then sees Disconnected. FIFO holds per sender; interleaving between producers is scheduling-dependent, so don't infer causality from queue order across threads.

The consumer can also end first, and then producers see Err(SendError<T>) on every subsequent send — the mirror-image EOF. A robust worker treats both ends as independently terminable: producers stop when sending fails or their work list empties; the consumer loops until recv reports disconnection. This "failure is a value" shape is what lets mpsc pipelines shut down cleanly without cancellation flags: the drops of the endpoint handles are the shutdown protocol, and every participant learns about it through its own API rather than through shared mutable state.

One debugging tip that saves hours: a pipeline that "stopped working" is usually a lifecycle bug, not a logic bug. Print or count the sender drops (a Drop impl on a small wrapper type, or simply log at the end of each producer), and check whether the consumer's recv loop is the last thing alive. Since recv gives you no visibility into how many senders remain, ownership structure is your only instrumentation — which is another argument for keeping all Sender clones in a Vec you control and dropping the Vec at the phase boundary, rather than scattering senders through the program where a stray clone can keep the channel half-open indefinitely.

Interview framing: "recv returns what, and when does it return Err?" is the canonical question: Result<T, RecvError>, blocking until a message or until all senders drop — and Err means EOF, never "empty." Strong candidates add the corollary: there's no close call; shutdown is by dropping senders, so accidentally-alive clones are a classic hang.

mpsc::channel() is unbounded: send never blocks, and a producer faster than its consumer grows the queue — and the process's memory — without limit. sync_channel(cap) trades that for backpressure — a bounded queue whose send blocks while the buffer is full:

use std::sync::mpsc::sync_channel;
use std::thread;

let (tx, rx) = sync_channel::<String>(4);      // capacity 4; 0 = rendezvous
let producer = thread::spawn(move || {
    for i in 0..100 { tx.send(format!("job {i}")).unwrap(); }   // blocks when full
});
let mut done = 0;
while let Ok(_job) = rx.recv() { done += 1; }   // draining unblocks the producer
producer.join().unwrap();

A capacity of 0 is the special rendezvous channel: send blocks until another thread is actually sitting in recv, so every message is a synchronous handoff. That makes sync_channel(0) a coordination primitive — two threads cannot race past each other; they must meet — which is often exactly the discipline a pipeline stage wants.

The deadlock catalogue for channels is worth memorizing. Full buffer, stalled consumer: sync_channel(n) deadlocks if the only thread that could drain is itself blocked — e.g. waiting to send on the same channel from inside its receive loop. Channels don't nest casually: receiving while holding a full outbound channel is a classic cycle. Blocking send with a half-dead pipeline: a producer blocked in send because the buffer is full resumes only if someone drains — but if the single consumer still owns rx yet stopped calling recv (blocked waiting on a lock, on another channel, or on that very producer's join), nothing drains and the send blocks forever. Unbounded channel() eliminates the full-buffer half of this but keeps the leaked-sender hang from the previous chapter. And unwrap on send during teardown: if the consumer ends first, send returns Err — a worker that unwraps panics, which (per Spawning Threads) kills only that thread and can cascade into "no producers left" for everyone else.

Choosing the bound is a policy decision interviewers like to probe: unbounded for bursty, loss-tolerant pipelines where memory is cheap; small bounded for producer-rate regulation (you want the producer slowed); rendezvous for strict handoff. And when the workload is "many threads mutate one shared structure," channels may not be the right shape at all — that's the Arc<Mutex<T>> territory of Arc and Mutex for Shared State, where you'll weigh ownership-per-message against lock-hold times.

A closing production note: std's mpsc is deliberately minimal — no select over multiple receivers, no priorities, no async integration (its blocking recv doesn't play well with async executors; async_channel or crossbeam cover those). Knowing the std floor and its boundaries is part of the answer: for straightforward worker pools and pipelines, channel/sync_channel plus clean drop discipline covers the design; the moment you need multi-consumer fan-out, cross-receiver selection, or non-blocking integration with an async runtime, that's the signal to reach for a fuller channel library rather than hand-rolling coordination on top of mpsc primitives.

Interview framing: "difference between channel() and sync_channel()" is the setup question; the answer to give is backpressure, with the rendezvous case (sync_channel(0)) as the memorable extreme. Then volunteer the deadlock pattern — blocking send + full buffer + a consumer that itself needs to send — to show you've built pipelines, not just read about them.