Avec l'introduction de Swift 5.5 et de la concurrence structurée, les développeurs ont été confrontés au défi de propager des métadonnées contextuelles — telles que des identifiants de requête, des jetons d'authentification ou des contextes de journalisation — à travers des piles d'appels asynchrones profondes sans polluer les signatures de fonction. Les approches traditionnelles s'appuyaient sur des variables globales ou un passage manuel explicite, ce qui introduisait soit des dangers de concurrence, soit des frictions dans l'API. TaskLocal a émergé comme la solution pour fournir un état implicite et lexicalement scindé qui respecte la hiérarchie de concurrence structurée.
Le défi principal réside dans le maintien d'un stockage de contexte isolé et sûr pour les threads qui suit automatiquement les relations parent-enfant des hiérarchies de Task. Contrairement au stockage local aux threads trouvé dans d'autres langages, le modèle de concurrence de Swift implique des pools de threads de vol de travail où les tâches migrent entre les threads, rendant le stockage local au thread invalide. De plus, la capture explicite dans les fermetures nécessiterait un passage manuel à travers chaque frontière asynchrone, rompant l'abstraction de la concurrence structurée.
Swift implémente le stockage local aux tâches en utilisant une pile de liaisons copy-on-write stockée dans le contexte interne de la tâche. Chaque instance de Task maintient un pointeur vers une liste chaînée (pile) de liaisons TaskLocal. Lorsqu'une tâche crée une tâche enfant, celle-ci reçoit une référence au sommet de la pile actuelle, héritant effectivement de toutes les liaisons parent. Lorsqu'une valeur est liée en utilisant .withValue(), un nouveau nœud de pile contenant la paire clé-valeur est ajouté à la pile de la tâche actuelle, masquant toute valeur précédente pour cette clé. Cette structure garantit que les recherches parcourent de la tâche actuelle vers ses ancêtres, permettant un temps de recherche de O(n) où n est la profondeur de liaison, tout en maintenant une création d'enfant à O(1).
enum TraceContext { @TaskLocal static var id: String? } await TraceContext.$id.withValue("trace-123") { await performDatabaseQuery() }
Considérons un système de traçage distribué pour un backend de microservices écrit en Swift. Chaque requête HTTP entrante génère un identifiant de trace unique qui doit se propager à travers des requêtes de base de données, des recherches dans le cache et des appels réseau sortants pour maintenir l'observabilité à travers les frontières de service.
Description du problème
La base de code contient des centaines de fonctions asynchrones à travers plusieurs couches : contrôleurs, services, dépôts et clients réseau. Passer l'identifiant de trace en tant que paramètre explicite à travers chaque signature de fonction nécessiterait de modifier des centaines de signatures de méthodes, rompant l'encapsulation et créant des cauchemars de maintenance. L'utilisation d'une variable globale échoue car le serveur gère des milliers de requêtes concurrentes ; une variable globale provoquerait des conditions de concurrence où les requêtes écraseraient les identifiants de trace des autres.
Différentes solutions envisagées
Une approche envisagée consistait à utiliser un conteneur d'injection de dépendances passé en tant qu'objet de contexte unique. Cela réduit le nombre de paramètres mais nécessite toujours de modifier chaque signature de fonction et crée un couplage étroit avec le type de conteneur. De plus, cela ne permet pas de se propager automatiquement à travers les frontières des bibliothèques tierces qui n'acceptent pas des paramètres de contexte personnalisés, rendant l'intégration difficile.
Une autre option impliquait le passage manuel de valeurs de tâche, où chaque opération asynchrone capturait explicitement l'identifiant de trace dans des contextes de fermetures. Cela garantit la correction mais entraîne une surcharge excessive, les développeurs devant se souvenir de capturer et de transmettre l'ID à chaque frontière asynchrone. Le risque d'erreur humaine oubliant de propager le contexte rend cette solution fragile et difficile à maintenir dans une grande équipe.
Solution choisie et raison
L'équipe a choisi le stockage TaskLocal pour conserver l'identifiant de trace. Cette approche a éliminé la nécessité de modifier les signatures de fonction tout en garantissant que l'identifiant de trace suit automatiquement l'arbre de concurrence structurée. Lorsqu'un gestionnaire de requêtes crée des tâches enfants pour des requêtes de base de données parallèles, chaque enfant hérite automatiquement de l'identifiant de trace du parent sans capture explicite. Cette solution respecte les garanties de sécurité de concurrence de Swift et nécessite des modifications minimales de code — seul le point d'entrée lie l'ID, et les consommateurs en aval le lisent implicitement.
Le résultat
L'implémentation a réduit de 95 % les changements de surface de l'API, supprimant les paramètres d'identifiant de trace de plus de 200 signatures de fonction. Le système a correctement maintenu l'isolement des traces entre les requêtes concurrentes, empêchant les problèmes de contamination croisée qui auraient pu survenir avec un état global. Le profilage de la mémoire a révélé que TaskLocal gérait efficacement le cycle de vie des valeurs liées, libérant automatiquement les références lorsque les tâches étaient terminées sans nécessiter de code de nettoyage manuel.
Comment TaskLocal se comporte-t-il lors de la création de tâches détachées par rapport à des tâches enfants structurées ?
Les candidats supposent souvent que toutes les tâches héritent des valeurs locales aux tâches de manière uniforme. Cependant, Task.detached rompt explicitement la chaîne d'héritage à des fins d'isolation. Lorsque vous créez une tâche détachée, elle reçoit un stockage local de tâche vide, empêchant les contextes sensibles de fuiter dans un travail intentionnellement isolé. En revanche, Task { } et TaskGroup créent des tâches héritent de la pile de liaison du parent. Cette distinction est cruciale pour les frontières de sécurité et les contextes de nettoyage des ressources où vous souhaitez vous assurer qu'aucun état implicite ne se transmet.
Quelles sont les implications de gestion de mémoire du lien de références fortes dans TaskLocal ?
Les développeurs oublient souvent que TaskLocal maintient une référence forte à toute valeur liée pendant toute la durée d'exécution de la tâche. Si vous liez un grand graphique d'objets ou une fermeture qui capture self, cette mémoire reste allouée jusqu'à la fin de la tâche, même si la valeur n'est plus accédée. Cela peut entraîner une pression mémoire inattendue ou des cycles de rétention si la valeur liée elle-même détient des références vers la tâche ou son contexte. Contrairement aux références faibles, le stockage local aux tâches ne se vide pas automatiquement lorsque la valeur n'est plus nécessaire ailleurs.
Les valeurs TaskLocal peuvent-elles être réidentifiées dans le même scope de tâche et comment cela affecte-t-il les tâches enfants concurrentes ?
Une idée reçue commune est que les valeurs locales de tâche sont immuables pendant la durée de la tâche. En réalité, appeler withValue pousse une nouvelle liaison sur la pile, masquant la valeur précédente. Les tâches enfants créées après un nouvel établissement voient la nouvelle valeur, mais les tâches enfants concurrentes existantes conservent la valeur de leur temps de création. Cela crée une sémantique d'instantané où chaque enfant voit une vue cohérente des locales de tâche basée sur le moment de sa création, similaire à la sémantique copy-on-write, garantissant que les mutations ultérieures dans le parent n'altèrent pas de manière inattendue le contexte d'exécution des enfants déjà en cours d'exécution.