Le retour de std::coroutine_handle depuis await_suspend permet un transfert symétrique, une forme garantie d'optimisation des appels en queue (TCO). Lorsque await_suspend renvoie void, le runtime de coroutine doit revenir à son appelant avant de reprendre la prochaine coroutine, créant une pile d'appels imbriqués qui croît linéairement avec la longueur de la chaîne. En retournant un handle, le compilateur génère un saut direct (jmp instruction) vers le point de reprise de la coroutine cible, réutilisant le registre d'activation actuel et maintenant une profondeur de pile constante O(1) indépendamment de la longueur de la chaîne.
struct SymmetricTransfer { std::coroutine_handle<> next; // Optimisé pour les appels en queue : pas de croissance de pile std::coroutine_handle<> await_suspend(std::coroutine_handle<>) { return next; } void await_resume() {} bool await_ready() { return false; } };
Nous avons développé un moteur de traitement audio en temps réel pour des logiciels de production musicale professionnels. Le système utilisait des coroutines C++20 pour représenter un pipeline de plus de 500 effets de traitement du signal numérique (DSP) (filtres, compresseurs, réverbérations) enchaînés. Lors des tests de stress, l'application s'est plantée avec un dépassement de pile lors du chargement de racks d'effets complexes, malgré le fait que chaque coroutine individuelle avait un état local minimal.
Solution 1 : await_suspend retournant void avec reprise directe L'implémentation initiale utilisait void await_suspend(std::coroutine_handle<>) et appelait next.resume() en interne. Cette approche offrait un flux de code intuitif et séquentiel, et facilitait le débogage par le biais des traces de pile standard. Cependant, chaque appel de resume() était imbriqué dans la logique de suspension de la coroutine précédente, consommant environ 16 Ko par étape et épuisant la pile de thread de 8 Mo après seulement 500 étapes.
Solution 2 : File de tâches avec planification asynchrone Nous avons envisagé de remplacer le chaînage direct par une file de tâches centralisée où chaque coroutine soumettait l'étape suivante comme un élément de travail et se suspendait immédiatement. Cela garantissait une utilisation constante de la pile en transformant la récursion en itération. L'inconvénient était une dégradation significative des performances : allocations dynamiques pour les nœuds de la file, désordre du cache dû à la contention des threads, et perte de la localité du cache entre les étapes du pipeline, violant nos exigences de latence de sub-millisecondes.
Solution 3 : Transfert symétrique via coroutine_handle Nous avons refactorisé await_suspend pour retourner le std::coroutine_handle de la prochaine étape directement. Cela a signalé au compilateur d'effectuer le TCO, fusionnant les cadres de pile. La solution a préservé l'abstraction sans coût des coroutines tout en garantissant une utilisation mémoire O(1). Le risque principal concernait la gestion de la durée de vie : une fois le handle retourné, la coroutine actuelle était suspendue, et l'accès à this ou aux variables locales après le point de retour entraînait un comportement indéfini.
Solution choisie et résultat Nous avons adopté la Solution 3. Après refactorisation, le pipeline a réussi à traiter 512 effets consécutifs n'utilisant que 4 Ko d'espace de pile, éliminant les plantages et maintenant des performances en temps réel déterministes. Ce changement a nécessité des revues de code minutieuses pour s'assurer qu'aucune logique post-retour n'existait dans await_suspend, mais a abouti à une architecture robuste et évolutive.
Pourquoi le transfert symétrique nécessite-t-il de retourner std::coroutine_handle plutôt que d'utiliser co_await sur la prochaine coroutine à l'intérieur de await_suspend ?
Utiliser co_await à l'intérieur de await_suspend nécessiterait que la coroutine en attente soit entièrement suspendue en premier lieu, puis reprise plus tard, ce qui implique intrinsèquement de revenir au runtime et de faire croître la pile. Retourner le handle directement permet au compilateur de traiter la reprise comme un appel de queue, tandis que co_await génère un point de suspension asymétrique qui doit préserver le cadre de l'appelant pour le reprendre plus tard.
Comment le transfert symétrique affecte-t-il la sécurité des exceptions si la coroutine reprise lance une exception avant d'atteindre son point de suspension final ?
Si la coroutine à laquelle on a transféré symétriquement lance une exception, l'exception se déploie à travers le cadre de await_suspend de manière conceptuelle, mais comme la coroutine originale est déjà marquée comme suspendue, son cadre doit être détruit lors du déroulement de la pile. Cela nécessite que le compilateur génère des tables de gestion d'exceptions complexes qui détruisent la promesse et les paramètres capturés de la coroutine suspendue. Les candidats oublient souvent que les allocateurs de type promise_type personnalisés doivent gérer correctement la construction partielle, sous peine de risquer des bugs de double-destruction lors du déroulement des exceptions.
Qu'est-ce qui empêche d'utiliser le transfert symétrique lors de la mise en œuvre d'un générateur qui restitue des valeurs d'une structure de données récursive ?
Les générateurs reposent sur co_yield pour retourner le contrôle à l'appelant tout en maintenant leur état. Le transfert symétrique transmet inconditionnellement le contrôle à une autre coroutine et ne revient jamais à l'appelant d'origine jusqu'à ce que l'ensemble de la chaîne soit terminé. Par conséquent, les générateurs doivent utiliser une suspension asymétrique (retournant void ou true depuis await_suspend) pour permettre au consommateur de recevoir la valeur restituée et potentiellement de reprendre le générateur plus tard, plutôt que de forcer un transfert irréversible vers une autre coroutine.