Les canaux, ou share memory by communicating Channels, or share memory by communicating

Et si la difficulté venait du partage — qu'on cesserait alors de partager ?What if the difficulty came from sharing — which we'd then stop doing?

Le numéro précédent a rouvert le partage mutable, mais au prix d'un verrou, d'une contention à doser et d'un deadlock qu'aucune preuve ne couvre. C'est le terrain difficile de la concurrence — et il le reste, même en Rust. Les canaux retournent le problème au lieu de l'affronter : plutôt que plusieurs threads se disputant une même mémoire mutable, un thread envoie un message, un autre le reçoit. La devise, empruntée à Go et faite sienne par Rust : « ne communique pas en partageant la mémoire ; partage la mémoire en communiquant ». Et le mécanisme qui rend cela sûr, on le connaît déjà : la possession de la donnée est déplacée à travers le canal — le move du Vol 1. L'émetteur la perd, le récepteur la gagne. À aucun instant deux threads ne la tiennent ensemble. Le data race n'est pas interdit : il devient impossible à exprimer, parce qu'il n'y a plus rien à partager.The previous issue reopened shared mutation, but at the price of a lock, of contention to balance, and of a deadlock no proof covers. That's concurrency's hard ground — and it stays hard, even in Rust. Channels flip the problem instead of fighting it: rather than several threads contending over the same mutable memory, one thread sends a message, another receives it. The motto, borrowed from Go and made Rust's own: 'don't communicate by sharing memory; share memory by communicating'. And the mechanism that makes this safe, we already know: ownership of the data is moved through the channel — Vol 1's move. The sender loses it, the receiver gains it. At no instant do two threads hold it together. The data race isn't forbidden: it becomes inexpressible, because there's nothing left to share.

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

let (tx, rx) = mpsc::channel();           // tx : l'émetteur · rx : le récepteur

thread::spawn(move || {
    let message = String::from("résultat");
    tx.send(message).unwrap();            // la possession de `message` ENTRE dans le canal
});                                       // (move : ce thread possède tx et message)

let recu = rx.recv().unwrap();            // …et RESSORT ici, côté récepteur
println!("{recu}");                       // un seul propriétaire à tout instant : rien n'est partagé

Ce qu'on envoie, on ne l'a plus : send déplace, il ne copie pas.What you send, you no longer have: send moves, it doesn't copy.

Pour qui vient d'un langage à GC, c'est la surprise du numéro, et elle est libératrice. Dans ces langages, « envoyer » un objet dans une file ou à un thread passe une référence : l'émetteur garde la sienne, et rien ne l'empêche de continuer à muter l'objet qu'un autre thread est en train de lire. C'est le data race classique, silencieux, qui ne se révèle qu'à l'exécution sous charge. En Rust, send(valeur) déplace la valeur : sa possession entre dans le canal, et l'émetteur n'a plus le droit d'y toucher — le compilateur le lui refuse, avec le E0382 du Vol 1. Ce n'est pas une restriction arbitraire : c'est précisément ce qui garantit qu'à tout instant, un seul thread possède la donnée. La sûreté du canal n'est pas dans le canal — elle est dans le move.For someone coming from a GC language, this is the issue's surprise, and it's liberating. In those languages, 'sending' an object to a queue or a thread passes a reference: the sender keeps its own, and nothing stops it from continuing to mutate the object another thread is reading. That's the classic data race, silent, surfacing only at runtime under load. In Rust, send(value) moves the value: its ownership enters the channel, and the sender no longer has the right to touch it — the compiler refuses, with Vol 1's E0382. It's not an arbitrary restriction: it's exactly what guarantees that, at any instant, a single thread owns the data. The channel's safety isn't in the channel — it's in the move.

let (tx, rx) = mpsc::channel();

let message = String::from("résultat");
tx.send(message).unwrap();           // `message` est DÉPLACÉ dans le canal

println!("{message}");               // ✕ error[E0382]: borrow of moved value: `message`
//   après send(), l'émetteur n'a plus rien : la donnée appartient au canal, puis
//   au récepteur. impossible de la lire des deux côtés → aucun aliasing → aucune course.
let _ = rx.recv();

L'erreur est, mot pour mot, celle du Vol 1 sur un String déplacé. Rien de spécifique aux threads : send prend la valeur (sa signature est send(self, t: T) — T par valeur), donc l'émetteur la perd. C'est ce qui rend le canal sûr par construction : puisque l'émetteur ne peut plus lire ce qu'il a envoyé, il ne peut pas y avoir deux threads sur la même donnée. Le compilateur transforme une discipline qu'on devait tenir à la main (« ne touche plus à ce que tu as envoyé ») en un théorème qu'il vérifie pour toi.The error is, word for word, Vol 1's on a moved String. Nothing thread-specific: send takes the value (its signature is send(self, t: T) — T by value), so the sender loses it. That's what makes the channel safe by construction: since the sender can no longer read what it sent, there can't be two threads on the same data. The compiler turns a discipline you had to hold by hand ('don't touch what you've sent') into a theorem it verifies for you.

Plusieurs émetteurs, un récepteur — et un canal qui se ferme quand le dernier tx meurt.Several senders, one receiver — and a channel that closes when the last tx dies.

mpsc se lit dans ses deux moitiés. Côté émission, le Sender est Clone : on en fait autant de copies qu'on a de producteurs, et tous alimentent la même file — c'est le « multi-producer ». Côté réception, le Receiver est unique, non clonable — le « single-consumer ». send() dépose une valeur (en la déplaçant) ; recv() en retire une, bloquant jusqu'à ce qu'elle arrive, et rend un Result. Reste la question décisive : comment le récepteur sait-il qu'il n'y aura plus rien ? La réponse est, une fois de plus, la possession. Quand le dernier Sender est détruit, le canal se ferme ; recv() rend alors une erreur, et la boucle for sur rx se termine d'elle-même. On ne compte pas les messages : on observe la mort des émetteurs.mpsc reads in its two halves. On the sending side, the Sender is Clone: you make as many copies as you have producers, and all feed the same queue — that's 'multi-producer'. On the receiving side, the Receiver is unique, non-clonable — 'single-consumer'. send() deposits a value (by moving it); recv() pulls one out, blocking until it arrives, and returns a Result. The decisive question remains: how does the receiver know nothing more will come? The answer is, once again, ownership. When the last Sender is destroyed, the channel closes; recv() then returns an error, and the for loop over rx ends on its own. You don't count messages: you observe the senders' death.

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

let (tx, rx) = mpsc::channel();

for id in 0..3 {
    let tx = tx.clone();                  // Sender est Clone : plusieurs PRODUCTEURS
    thread::spawn(move || {
        tx.send(format!("de {id}")).unwrap();
    });                                   // chaque clone de tx est lâché en fin de thread
}
drop(tx);                                 // ← on lâche le tx ORIGINEL (sinon le canal ne ferme jamais)

for recu in rx {                          // itère tant qu'un Sender vit ; déballe automatiquement
    println!("{recu}");
}                                         // la boucle se termine quand le DERNIER Sender meurt

let trois = rx.recv();           // BLOQUE jusqu'au prochain message (ou Err si canal fermé)
let peut_etre = rx.try_recv();   // NE bloque pas : Ok(v), ou Err(Empty), ou Err(Disconnected)

// recv() rend Result<T, RecvError> : l'Err signale « plus aucun Sender, rien ne viendra ».
// c'est ainsi qu'un récepteur sait s'arrêter — pas par un compteur, mais par la fermeture
// du canal, déclenchée par le drop du dernier émetteur. la possession, encore, fait le travail.

Un Sender oublié, vivant — et le récepteur attend un message pour toujours.One forgotten Sender, still alive — and the receiver waits for a message forever.

Le canal supprime le deadlock sur les données — mais il en introduit un qui lui est propre, et qui piège tout le monde une fois. La boucle for sur un récepteur ne se termine que lorsque le canal se ferme, et le canal ne se ferme que lorsque le dernier Sender est détruit. Or il est facile d'en laisser un vivant sans le vouloir : l'émetteur originel qu'on a cloné pour les threads mais jamais lâché, un tx capturé dans une structure, un clone gardé « au cas où ». Tant qu'un seul Sender respire, le récepteur croit que d'autres messages peuvent arriver, et recv() bloque indéfiniment. Le programme se fige — pas sur un verrou, mais sur l'attente d'un message qui ne viendra jamais. Ça compile sans le moindre avertissement : comme le deadlock du №2, c'est une faute de logique, pas de type. La discipline tient en trois mots : compte tes Senders.The channel removes the deadlock on data — but it introduces one of its own, which traps everyone once. The for loop over a receiver only ends when the channel closes, and the channel only closes when the last Sender is destroyed. Yet it's easy to leave one alive unwittingly: the original sender you cloned for the threads but never dropped, a tx captured in a struct, a clone kept 'just in case'. As long as a single Sender breathes, the receiver believes more messages may come, and recv() blocks indefinitely. The program freezes — not on a lock, but on waiting for a message that will never come. It compiles without the slightest warning: like №2's deadlock, it's a logic fault, not a type fault. The discipline fits in three words: count your Senders.

let (tx, rx) = mpsc::channel();

for id in 0..3 {
    let tx = tx.clone();
    thread::spawn(move || { tx.send(id).unwrap(); });
}
// ✕ on a OUBLIÉ de lâcher `tx` : l'émetteur originel reste vivant dans ce scope.

for recu in rx {                     // les 3 messages arrivent… puis la boucle ATTEND
    println!("{recu}");              // un 4ᵉ message qui ne viendra jamais.
}                                    // ↻ le programme se FIGE — pas un deadlock de verrou,
                                     //   mais un canal qui ne ferme pas. et ça compile.

let (tx, rx) = mpsc::channel();

for id in 0..3 {
    let tx = tx.clone();
    thread::spawn(move || { tx.send(id).unwrap(); });
}
drop(tx);                            // ✓ on lâche explicitement l'émetteur originel

for recu in rx {                     // dès que les 3 clones ET l'original sont lâchés,
    println!("{recu}");              // le canal ferme, la boucle se termine proprement.
}
// règle : la boucle for sur rx finit EXACTEMENT quand le dernier Sender meurt. compte tes tx.

Le drop(tx) n'est pas une cérémonie : c'est l'acte qui annonce la fin. Souvent on l'évite plus élégamment en ne gardant jamais l'émetteur originel — on le move entièrement dans le code producteur, ou on enferme les tx dans un scope qui se referme. Mais quel que soit le style, la règle est invariable : la boucle for sur rx se termine quand, et seulement quand, le dernier Sender est détruit. Si ton programme se fige à la fin, ne cherche pas un verrou : cherche le tx que tu as oublié de laisser mourir.The drop(tx) isn't ceremony: it's the act that announces the end. Often you avoid it more elegantly by never keeping the original sender — you move it entirely into the producer code, or enclose the txs in a scope that closes. But whatever the style, the rule is invariable: the for loop over rx ends when, and only when, the last Sender is destroyed. If your program freezes at the end, don't look for a lock: look for the tx you forgot to let die.