Comprendre ce qu'est une runtime asynchrone en Rust et le fonctionnement de Tokio

En Rust, contrairement à Node.js ou Go, le développeur doit choisir sa runtime asynchrone, souvent Tokio. Cette runtime gère les opérations non bloquantes (comme async/await) en utilisant des futures, équivalents des promesses JavaScript. L'architecture repose sur trois niveaux : le programme, la runtime (Tokio) et le système d'exploitation. Mio, le réacteur de Tokio, sert d'interface avec le système (epoll, kqueue) pour surveiller les entrées/sorties. Dès qu'une opération (lecture, écriture) est terminée, Mio notifie Tokio, qui résout la future correspondante et permet au code de continuer sans bloquer le thread.

Chaque appel async/await crée une tâche placée dans une file d'attente. L'exécuteur de Tokio distribue ces tâches à des workers, un par thread par défaut. Chaque worker possède sa propre file. Si un worker termine sa file, il peut « voler » des tâches d'un autre worker pour équilibrer la charge, optimisant ainsi l'utilisation des cœurs processeur.

Exemple : Lors d'une requête réseau, le code attend le résultat. Au lieu de bloquer le thread, Tokio suspend la tâche. Mio détecte l'arrivée des données réseau, notifie Tokio, qui réactive la tâche. Le worker reprend l'exécution avec les données, sans avoir immobilisé le thread pendant l'attente.