Pourquoi le blocage : raisons derrière les destructeurs bloquants des futurs renvoyés par std::async

Lorsque vous travaillez avec des tâches asynchrones, le destructeur de un futur renvoyé par std::async est connu pour son comportement bloquant, soulevant des questions sur sa nécessité. Pour approfondir ce choix de conception, explorons les préoccupations et les discussions qui ont conduit à sa mise en œuvre.

L'article de Herb Sutter, "async, ~future, and ~thread", met en évidence les considérations de sécurité liées au blocage des destructeurs. Sans ce comportement, un thread « fugitif » associé au futur pourrait continuer à s'exécuter après la destruction de son état associé. Ce manque de contrôle sur l'achèvement des tâches pourrait potentiellement conduire à une corruption de la mémoire ou à d'autres problèmes inattendus.

L'article de Hans Boehm, "Les futurs destructeurs Async() doivent attendre", fournit un exemple concret de cette préoccupation. Sans blocage des destructeurs, la gestion des exceptions ou des événements externes pourraient perturber le flux attendu d’exécution des tâches. Comme le souligne Boehm, cela pourrait créer une vulnérabilité de sécurité dans laquelle un attaquant pourrait manipuler le timing des exceptions pour exploiter une omission dans les gardes de portée, conduisant à l'écrasement de la pile et au détournement de processus.

Le destructeur bloquant sert de protection contre ces dangers potentiels, empêchant le thread associé de poursuivre son exécution après la destruction du futur. Cependant, il est important de noter que ce comportement est spécifique aux futures renvoyés par std::async avec une politique de lancement asynchrone. D'autres futurs, tels que ceux renvoyés par std::promise ou les futurs d'algorithmes parallèles, ne présentent pas le même comportement de blocage dans leurs destructeurs.

Malgré les problèmes de sécurité soulevés, le destructeur bloquant des futurs std::async a été un sujet de débat en cours au sein du comité de normalisation C. Les modifications proposées visant à déprécier le comportement de blocage ou à le rendre non standard pour les contrats à terme asynchrones n'ont pas été adoptées.

En résumé, les destructeurs bloquants des contrats à terme renvoyés par std::async sont un choix de conception controversé motivé par des problèmes de sécurité. . Bien qu'il évite les problèmes potentiels liés à l'exécution incontrôlée des threads, il introduit également la nécessité d'une gestion explicite du cycle de vie des threads et des gardes de portée pour garantir un nettoyage approprié.