Annuler, sélectionner, structurer Cancel, select, structure

Le troisième visage du .await : un endroit où la tâche peut être interrompue.The third face of .await: a place where the task can be interrupted.

On a vu le .await sous deux angles : un point de suspension où l'exécuteur reprend la main (№1), un point de migration où la donnée tenue doit être Send (№2). En voici le troisième, et il clôt le volume : un point d'annulation. Un Future n'avance que tant qu'on le poll. Cesse de le poller — laisse-le tomber, drop-le — et il s'arrête à son dernier .await, définitivement : ce qu'il n'avait pas fini ne sera jamais fait. C'est radicalement différent des threads du Vol 7, qu'on ne pouvait pas interrompre proprement de l'extérieur. En async, l'annulation n'est pas un mécanisme spécial à câbler : elle est dans le modèle. Un timeout, une course entre deux requêtes, un serveur qu'on arrête — tout cela s'exprime en arrêtant de poller certains Futures. Annuler, c'est drop.We've seen .await from two angles: a suspension point where the executor takes back control (№1), a migration point where held data must be Send (№2). Here's the third, and it closes the volume: a cancellation point. A Future only advances while it's polled. Stop polling it — let it fall, drop it — and it stops at its last .await, for good: what it hadn't finished will never be done. This is radically different from Vol 7's threads, which you couldn't cleanly interrupt from outside. In async, cancellation isn't a special mechanism to wire up: it's in the model. A timeout, a race between two requests, a server you shut down — all of it is expressed by ceasing to poll certain Futures. To cancel is to drop.

use tokio::time::{timeout, Duration};

// timeout pilote `requete()` ; si 5 s passent, il LÂCHE le Future — qui s'arrête net.
match timeout(Duration::from_secs(5), requete()).await {
    Ok(reponse) => traiter(reponse),
    Err(_)      => println!("trop lent — la requête a été ANNULÉE"),
}
// annuler, ici, ce n'est PAS envoyer un signal : c'est cesser de poller le Future.
// il s'arrête à son dernier .await, et ce qu'il n'avait pas fini ne sera jamais fait.

select! garde le premier prêt — et abandonne les autres en plein vol.select! keeps the first ready — and abandons the others mid-flight.

select! est l'outil qui fait courir plusieurs Futures et garde le premier qui aboutit. Mais la moitié de son comportement est dans ce qu'il fait aux perdants : il les drop. Pour qui vient de JavaScript, c'est la surprise du numéro, et l'inverse exact de Promise.race. Là-bas, la course renvoie la première promesse résolue, mais les autres continuent à tourner en arrière-plan — la requête lente finit quand même, avec ses effets de bord et son coût, simplement on ignore son résultat. En Rust, les branches perdantes de select! sont annulées : leurs Futures sont lâchés à l'instant où une autre gagne, là où ils en étaient dans leur .await. Le travail en cours s'arrête. C'est plus propre — rien ne traîne — mais ça veut dire qu'une branche peut être interrompue au pire moment, et c'est exactement ce qui rend la cancellation safety nécessaire.select! is the tool that races several Futures and keeps the first to complete. But half its behaviour is in what it does to the losers: it drops them. For someone from JavaScript, that's the issue's surprise, and the exact inverse of Promise.race. There, the race returns the first resolved promise, but the others keep running in the background — the slow request finishes anyway, with its side effects and cost, you just ignore its result. In Rust, select!'s losing branches are cancelled: their Futures are dropped the instant another wins, wherever they were in their .await. The in-progress work stops. It's cleaner — nothing lingers — but it means a branch can be interrupted at the worst moment, and that's exactly what makes cancellation safety necessary.

tokio::select! {
    reponse = serveur_a() => utiliser(reponse),   // si A gagne…
    reponse = serveur_b() => utiliser(reponse),   // …B est LÂCHÉ là où il en était (et inversement)
}
// select! garde la PREMIÈRE branche prête et DROP les autres, en plein .await.
// le perdant ne tourne pas en arrière-plan : il est annulé, point — sa requête s'arrête.

L'annulation des perdants découle directement du chapitre 1 : select! cesse de poller les branches qui n'ont pas gagné, donc leurs Future sont drop. Leurs ressources sont nettoyées (RAII), leurs requêtes interrompues. C'est idéal pour un timeout — « la réponse, ou deux secondes » — ou pour réagir au premier de plusieurs événements. Mais retiens ce que ça implique : une branche qui perd est arrêtée en plein milieu de ce qu'elle faisait. Si elle avait lu la moitié d'un message, cette moitié part avec elle.The cancellation of losers follows directly from chapter 1: select! stops polling the branches that didn't win, so their Futures are dropped. Their resources are cleaned up (RAII), their requests interrupted. It's ideal for a timeout — 'the response, or two seconds' — or to react to the first of several events. But remember what it implies: a losing branch is stopped in the very middle of what it was doing. If it had read half a message, that half goes with it.

join! attend tout le monde ; select! garde le premier — et Drop fait le ménage.join! awaits everyone; select! keeps the first — and Drop cleans up.

Deux combinateurs, deux intentions. join! prend plusieurs Futures, les fait avancer ensemble, et ne rend la main que lorsque tous ont fini — il rend un tuple de tous les résultats. select! prend plusieurs Futures, les fait avancer ensemble aussi, mais s'arrête au premier prêt, et lâche les autres. Point crucial, hérité du Vol 8 №1 : dans les deux cas, ces Futures tournent sur une seule tâche, entrelacés par l'exécuteur — c'est de la concurrence, pas du parallélisme. Pour du vrai parallélisme sur plusieurs threads, il faut tokio::spawn, qui détache une tâche indépendante. Et le mécanisme d'annulation est, lui, d'une simplicité élégante : annuler = drop, et drop déclenche le nettoyage via l'impl Drop (RAII, Vol 1). Fermer une connexion, relâcher un verrou, annuler une transaction : si c'est dans un Drop, l'annulation le fait pour toi.Two combinators, two intentions. join! takes several Futures, advances them together, and only returns when all have finished — it yields a tuple of all results. select! takes several Futures, advances them together too, but stops at the first ready, and drops the others. Crucial point, inherited from Vol 8 №1: in both cases, these Futures run on a single task, interleaved by the executor — it's concurrency, not parallelism. For true parallelism across threads, you need tokio::spawn, which detaches an independent task. And the cancellation mechanism is elegantly simple: cancel = drop, and drop triggers cleanup via the Drop impl (RAII, Vol 1). Closing a connection, releasing a lock, rolling back a transaction: if it's in a Drop, cancellation does it for you.

// join! : attend que TOUTES finissent, garde tout, rend un tuple
let (a, b, c) = tokio::join!(charger_a(), charger_b(), charger_c());

// select! : garde la PREMIÈRE prête, DROP les autres
let valeur = tokio::select! {
    v = travail()                       => v,
    _ = tokio::time::sleep(DEUX_S)      => defaut(),   // un timeout, exprimé comme une branche
};
// les deux font tourner plusieurs Futures sur UNE seule tâche : concurrence, pas parallélisme.

struct Connexion { /* … */ }
impl Drop for Connexion {
    fn drop(&mut self) { self.fermer(); }   // le nettoyage est ICI (RAII, Vol 1)
}

async fn servir(c: Connexion) { boucle(c).await }
// si le Future de servir() est annulé (drop), `c` est drop → fermer() s'exécute.
// l'annulation déclenche le nettoyage des ressources, automatiquement. c'est ça,
// la « concurrence structurée » au niveau le plus simple : Drop fait le ménage.

Une branche annulée au mauvais .await — et le travail à moitié fait disparaît.A branch cancelled at the wrong .await — and the half-done work vanishes.

Voici le piège qui donne son nom au numéro, et qui ne se révèle qu'en production. On a vu que select! annule les branches perdantes en plein .await. Tant que l'opération annulée n'avait rien entamé d'irréversible, aucun problème. Mais certaines opérations sont multi-étapes : elles lisent un bout, attendent, lisent la suite. Si l'annulation tombe entre deux étapes, le travail déjà fait — les octets lus, l'élément à moitié consommé — part avec le Future abandonné. C'est ce qu'on appelle la cancellation safety : une opération async est cancel-safe si, annulée à n'importe quel .await, elle ne perd aucun travail (soit elle a fini, soit elle n'a rien entamé). read_exact ne l'est pas ; recv() d'un canal l'est. Le danger est sournois parce qu'il n'apparaît jamais dans les tests heureux : il faut que l'annulation tombe pile au mauvais moment, sous charge, pour corrompre un flux.Here's the trap that names the issue, and that only surfaces in production. We've seen that select! cancels losing branches mid-.await. As long as the cancelled operation had started nothing irreversible, no problem. But some operations are multi-step: they read a chunk, wait, read more. If cancellation falls between two steps, the work already done — the bytes read, the half-consumed item — goes with the abandoned Future. This is called cancellation safety: an async operation is cancel-safe if, cancelled at any .await, it loses no work (either it finished, or it started nothing). read_exact isn't; a channel's recv() is. The danger is insidious because it never shows in the happy tests: cancellation must fall at exactly the wrong moment, under load, to corrupt a stream.

loop {
    tokio::select! {
        // ✕ read_exact n'est PAS cancel-safe : s'il est annulé en pleine lecture,
        //   les octets déjà placés dans `buf` sont PERDUS (l'appel repart de zéro).
        r = socket.read_exact(&mut buf) => traiter(&buf),
        _ = shutdown.recv()            => break,   // si shutdown gagne pendant un read partiel…
    }
}                                                  // …les octets à moitié lus disparaissent avec la branche.

// le réflexe : dans un select! en boucle, n'utilise QUE des opérations cancel-safe
loop {
    tokio::select! {
        Some(msg) = canal.recv() => traiter(msg),  // ✓ recv() EST cancel-safe : rien à moitié lu
        _ = shutdown.recv()      => break,
    }
}
// et si une opération ne l'est pas (read_exact…) ? sors-la du select! : confie-la à une tâche
// dédiée, ou garde son état partiel TOI-MÊME entre deux tours — jamais dans la branche annulable.

La parade n'est pas d'éviter select! — c'est de ne lui confier que des opérations qui survivent à l'annulation. Le recv() d'un canal est cancel-safe : annulé, il n'a rien retiré du canal, le message est toujours là au tour suivant. Pour une opération qui ne l'est pas, deux sorties : la déplacer hors du select! (dans une tâche spawn qui la mène à terme à l'abri de l'annulation), ou posséder soi-même l'état partiel entre deux tours de boucle, de sorte qu'une annulation ne jette rien. La règle tient en une vérification : dans un select! répété, chaque branche doit pouvoir être coupée à son .await sans rien perdre.The fix isn't to avoid select! — it's to entrust it only with operations that survive cancellation. A channel's recv() is cancel-safe: cancelled, it removed nothing from the channel, the message is still there next round. For an operation that isn't, two exits: move it out of the select! (into a spawned task that drives it to completion, shielded from cancellation), or own the partial state yourself across loop rounds, so a cancellation discards nothing. The rule fits in one check: in a repeated select!, each branch must be able to be cut at its .await without losing anything.