Le problème des fonctions colorées The colored functions problem

Le mot-clé ne reste pas où on le pose : async remonte toute la pile d'appels.The keyword doesn't stay put: async climbs the whole call stack.

Le numéro précédent a regardé un Future seul, comme s'il vivait isolé. Il n'en est rien : appeler de l'async a une conséquence qui déborde la fonction. Pour obtenir la valeur d'un Future, on l'await ; mais .await n'est permis que dans un contexte async. Donc une fonction qui await devient elle-même async, et celle qui l'appelle aussi, et ainsi de suite jusqu'au main. C'est ce qu'on appelle le « problème des fonctions colorées » : il existe deux couleurs de fonctions, synchrone et asynchrone, et la couleur async se propage de proche en proche dès qu'on l'introduit quelque part. On ne peut pas appeler simplement une async fn depuis du code synchrone — les deux mondes ne se composent pas librement. C'est la friction promise à la fin du №1 : la couleur a un prix, et il se paie sur toute la chaîne d'appels.The previous issue looked at a Future alone, as if it lived in isolation. It doesn't: calling async has a consequence that overflows the function. To get a Future's value, you await it; but .await is only allowed in an async context. So a function that awaits becomes async itself, and its caller too, and so on up to main. This is the 'colored functions problem': there are two colors of function, synchronous and asynchronous, and the async color propagates step by step the moment you introduce it somewhere. You can't simply call an async fn from synchronous code — the two worlds don't compose freely. It's the friction promised at the end of №1: color has a price, and it's paid across the whole call chain.

async fn lire_config() -> Config { /* … .await … */ }

async fn demarrer() -> Config {     // ← DOIT être async : elle .await lire_config
    let cfg = lire_config().await;
    valider(cfg)
}

#[tokio::main]
async fn main() {                   // ← async aussi, remontée jusqu'à la racine
    let cfg = demarrer().await;
}
// la couleur remonte : quiconque .await de l'async DOIT être async lui-même (ou ouvrir un runtime).

Du code synchrone ne peut pas .await — et il n'existe qu'un pont.Synchronous code can't .await — and there's only one bridge.

La couleur ne serait qu'une gêne théorique si les deux mondes communiquaient librement. Ils ne le font pas, et c'est la surprise concrète du numéro. Dans une fonction synchrone, écrire .await est une erreur de compilation pure et simple : await n'est permis que dans un contexte async. Tu ne peux donc pas glisser un appel async dans une méthode de trait synchrone, dans une closure passée à un Iterator::map, dans un Drop — partout où l'API attend du code sync, l'async est interdit de séjour. Et dans l'autre sens, déclencher du async depuis du sync demande une machinerie explicite : ouvrir un runtime et appeler block_on. Ce pont existe, mais il bloque le thread — donc il n'a sa place qu'à la racine du programme, jamais au milieu d'une chaîne asynchrone.Color would be a mere theoretical nuisance if the two worlds talked freely. They don't, and that's the issue's concrete surprise. In a synchronous function, writing .await is a plain compile error: await is only allowed in an async context. So you can't slip an async call into a synchronous trait method, into a closure passed to Iterator::map, into a Drop — anywhere the API expects sync code, async is barred. And the other way, triggering async from sync demands explicit machinery: open a runtime and call block_on. That bridge exists, but it blocks the thread — so it belongs only at the program's root, never in the middle of an async chain.

fn charger() -> Config {            // fonction SYNCHRONE (non colorée)
    let cfg = lire_config().await;  // ✕ error[E0728]: `await` is only allowed inside
    cfg                             //   `async` functions and blocks
}
// et sans .await ? lire_config() rend juste un Future inerte (№1) — la config n'est
// jamais chargée. dans du sync, on ne peut NI attendre, NI déclencher proprement un Future.

L'erreur E0728 est catégorique. La fonction n'est pas colorée, donc elle n'a aucun exécuteur sous la main pour piloter le Future ; .await n'a littéralement aucun sens ici. La seule façon « propre » de lever l'erreur dans le corps même de charger serait de colorer charger en async — c'est-à-dire de propager la couleur, exactement comme au chapitre 1. C'est ce qui rend l'async collant : on ne le contient pas en l'enfermant dans une fonction, il déborde par construction.The E0728 error is categorical. The function isn't colored, so it has no executor at hand to drive the Future; .await literally makes no sense here. The only 'clean' way to lift the error in charger's very body would be to color charger as async — that is, to propagate the color, exactly as in chapter 1. That's what makes async sticky: you don't contain it by enclosing it in a function, it overflows by construction.

La couleur n'est pas un caprice : c'est la frontière de l'exécuteur.The color isn't a whim: it's the executor boundary.

Pourquoi ne peut-on pas simplement appeler une async fn n'importe où ? Parce que la valeur d'un Future ne s'obtient qu'en le pollant jusqu'à Ready — et poller, c'est le travail de l'exécuteur, qui n'existe que dans le monde async. Une fonction synchrone court jusqu'au bout sur sa pile : elle ne sait pas suspendre, ni rendre la main, ni reprendre plus tard. Une fonction async, elle, est une machine à états qu'un exécuteur fait avancer entre des points de suspension. Ce sont deux régimes d'exécution incompatibles, et la « couleur » n'est que le nom de cette frontière. Le runtime est ce qui la franchit, et il ne la franchit qu'en un seul sens propre : block_on, à la racine, fait entrer le thread synchrone dans le monde async. Une fois dedans, plus de frontière : .await en séquentiel, join! en concurrent, spawn pour des tâches indépendantes — tout compose.Why can't you just call an async fn anywhere? Because a Future's value is only obtained by polling it to Ready — and polling is the executor's job, which exists only in the async world. A synchronous function runs to the end on its stack: it can't suspend, yield, or resume later. An async function, by contrast, is a state machine an executor advances between suspension points. These are two incompatible execution regimes, and 'color' is just the name of that boundary. The runtime is what crosses it, and it crosses it cleanly in only one direction: block_on, at the root, brings the synchronous thread into the async world. Once inside, no more boundary: .await for sequential, join! for concurrent, spawn for independent tasks — everything composes.

// pourquoi la couleur existe : pour OBTENIR la valeur d'un Future, il faut le
// POLLER jusqu'à Ready (№1) — donc être piloté par un exécuteur. seul le monde async l'est.
async fn valeur() -> i32 { 42 }

// dans du sync, valeur() rend un Future inerte : aucun exécuteur pour le faire avancer.
// .await veut dire « pilote ce Future via l'exécuteur courant » → encore faut-il qu'il y en ait un.
// la frontière n'est pas un caprice : c'est la limite entre « je peux suspendre » et « je cours
// jusqu'au bout sur la pile ». le runtime est le SEUL pont entre les deux.

#[tokio::main]
async fn main() {
    // DANS le monde async, tout compose sans friction :
    let a = etape_un().await;               // séquentiel : on attend a avant la suite
    let (x, y) = tokio::join!(f(), g());    // concurrent : deux Futures sur LA MÊME tâche
    let h = tokio::spawn(tache());          // tâche INDÉPENDANTE, confiée au runtime
    let r = h.await.unwrap();               // spawn rend un JoinHandle — l'écho du thread (Vol 7)
}

La donnée tenue à travers un .await doit être Send — le Vol 7 ressurgit.Data held across a .await must be Send — Vol 7 resurfaces.

Voici la contrainte que la couleur fait surgir, et qui pince tout le monde une fois. Sur un runtime multi-thread, une tâche peut changer de thread à chaque point de suspension : elle est pollée sur le thread A, rend Pending au .await, et reprend plus tard sur le thread B. Conséquence directe : tout ce que la tâche tient à travers un .await traverse potentiellement une frontière de threads — et doit donc être Send, au sens exact du Vol 7. C'est pourquoi tokio::spawn exige que le Future entier soit Send. Le bug classique : tenir, à travers un .await, un MutexGuard de std::sync::Mutex, un Rc, ou un emprunt de RefCell — autant de types !Send. Le compilateur refuse alors le spawn avec un message qui parle de Send au beau milieu de ton code async. La concurrence du Vol 7 n'avait pas disparu ; elle attendait sous l'async.Here's the constraint color brings out, the one that pinches everyone once. On a multi-threaded runtime, a task can change thread at each suspension point: it's polled on thread A, returns Pending at .await, and resumes later on thread B. Direct consequence: everything the task holds across a .await potentially crosses a thread boundary — and so must be Send, in Vol 7's exact sense. That's why tokio::spawn requires the whole Future to be Send. The classic bug: holding, across a .await, a MutexGuard from std::sync::Mutex, an Rc, or a RefCell borrow — all !Send types. The compiler then refuses the spawn with a message about Send in the middle of your async code. Vol 7's concurrency hadn't vanished; it was waiting beneath async.

use std::sync::Mutex;

async fn incrementer(etat: Arc<Mutex<i32>>) {
    let mut n = etat.lock().unwrap();    // garde un MutexGuard (std) — il n'est PAS Send
    *n += 1;
    sauvegarder().await;                 // ✕ on tient le guard À TRAVERS le .await
}                                        //   → tout le Future devient !Send

// tokio::spawn(incrementer(etat))  →  error: future cannot be sent between threads safely
//   within `incrementer`, the trait `Send` is not implemented for `MutexGuard<'_, i32>`
// et même sans spawn : tenir un verrou à travers une suspension est une invite au deadlock.

async fn incrementer(etat: Arc<Mutex<i32>>) {
    {
        let mut n = etat.lock().unwrap();   // ✓ verrou pris dans un bloc ÉTROIT
        *n += 1;
    }                                       // ← le guard est LÂCHÉ ici, AVANT le .await
    sauvegarder().await;                    // plus rien de !Send tenu à travers : le Future est Send
}
// règle : ne tiens jamais un MutexGuard (ni un Rc, ni un emprunt de RefCell) à travers un .await.
// si tu DOIS garder le verrou pendant l'attente → tokio::sync::Mutex, dont le guard EST Send.

La correction tient en un bloc : prendre le verrou, faire la mutation, relâcher le guard avant le .await. Le Future ne tient alors plus rien de !Send à travers la suspension, et redevient Send. Le bénéfice est double, et c'est ce qui rend la règle si saine : non seulement on satisfait Send, mais on évite de tenir un verrou pendant une attente — un anti-pattern qui sérialise et invite au deadlock, exactement comme au №2 du Vol 7. Si l'attente doit vraiment se faire verrou en main, c'est le signe qu'il faut un Mutex asynchrone (tokio::sync::Mutex), dont le guard est conçu pour traverser un .await.The fix fits in one block: take the lock, do the mutation, release the guard before the .await. The Future then holds nothing !Send across the suspension, and becomes Send again. The benefit is twofold, and that's what makes the rule so healthy: not only do you satisfy Send, you avoid holding a lock during a wait — an anti-pattern that serializes and invites deadlock, exactly as in Vol 7 №2. If the wait truly must happen lock in hand, that's the sign you need an asynchronous Mutex (tokio::sync::Mutex), whose guard is designed to cross a .await.