Swift relie les fermetures à C et Objective-C via des fonctions de thunk générées par le compilateur et des transformations de disposition mémoire spécifiques. Pour @convention(c), le compilateur exige que la fermeture ait une liste de capture vide car les pointeurs de fonction C sont des adresses brutes sans paramètres de contexte, empêchant toute référence aux variables de portée externe. Pour @convention(block), le compilateur génère une structure de bloc Objective-C sur le tas, complète avec un pointeur isa, des indicateurs, un pointeur de fonction d'invocation et une disposition de variable capturée, permettant à ARC de gérer la durée de vie du bloc par des cycles de maintien/libération. L'invariant critique est que les fermetures @convention(c) ne doivent pas capturer de références à des objets alloués sur le tas pour éviter les pointeurs suspendus, tandis que les fermetures @convention(block) doivent s'assurer que les références capturées sont maintenues pendant la durée de la vie du bloc dans le code Objective-C.
Lors du développement d'une bibliothèque de traitement audio en temps réel, l'équipe avait besoin d'enregistrer des fonctions de rappel avec l'API C de Core Audio (AURenderCallback) tout en exposant des gestionnaires de complétion aux API d'animation basées sur Objective-C de UIKit. Le défi principal était de passer des fermetures Swift qui capturaient self et l'état du tampon audio à ces interfaces de fonctions étrangères sans violer la sécurité de la mémoire ou introduire des cycles de maintien. Les contraintes exigeaient un accès sans surcoût aux tampons audio tout en maintenant la sécurité des threads entre le thread audio en temps réel et le thread principal de l'interface utilisateur.
Une approche envisagée était d'utiliser un gestionnaire singleton avec des fonctions statiques globales pour les rappels C. Cette méthode stockait le contexte dans un dictionnaire local au thread indexé par des pointeurs d'unité audio. Bien qu'elle évitât les problèmes de capture, elle introduisait une complexité de sécurité des threads et un état mutable global difficile à tester.
Une autre approche consistait à créer des classes d'enveloppe Objective-C pour contenir les fermetures Swift et exposer des pointeurs de fonction C qui désérialisaient l'enveloppe via un paramètre de contexte void*. Bien que maintenue, cela ajoutait un surcoût de pont et nécessitait des appels de maintien/libération manuels pour éviter la désallocation prématurée. La gestion manuelle de la mémoire risquait des fuites si le cycle de vie de l'enveloppe n'était pas parfaitement synchronisé avec l'initialisation et le démantèlement de l'unité audio.
La solution choisie a tiré parti de @convention(c) pour les rappels Core Audio en passant un pointeur de contexte unsafeBitCast explicite vers une structure contenant des références faibles à l'engin audio, combiné avec @convention(block) pour les complétions sur UIKit. Cela a éliminé l'état global tout en garantissant que ARC gérait correctement les blocs Objective-C. Des barrières de mémoire explicites protégeaient les pointeurs de contexte C pendant les transitions entre threads audio.
Le résultat était un pont C sans surcoût avec une utilisation mémoire déterministe. Le système ne mettait pas en évidence de cycles de maintien dans la couche d'interface utilisateur, et le traitement audio respectait les contraintes de performances en temps réel sans verrous globaux.
Pourquoi Swift interdit-il les captures dans les fermetures @convention(c) à un niveau de langage ?
Les pointeurs de fonction C sont représentés comme de simples adresses mémoire sans support pour un contexte implicite ou un paramètre "userdata". Cela signifie que toute fermeture capturant des variables externes aurait besoin d'un endroit pour stocker ces références que le code C ne peut pas fournir. Swift impose cette contrainte au moment de la compilation pour empêcher les développeurs de créer accidentellement des fermetures qui référencent de la mémoire de pile ou de tas. De telles références deviendraient des pointeurs suspendus une fois que le pointeur de fonction C survivrait au contexte Swift.
Comment ARC gère-t-il le cycle de vie d'une fermeture @convention(block) lorsqu'elle est passée à un code Objective-C qui la stocke au-delà de la portée actuelle ?
Lorsque Swift convertit une fermeture en @convention(block), le compilateur émet une structure de bloc Objective-C allouée sur le tas. Cette structure suit la disposition mémoire de NSObject, permettant à ARC d'appliquer les opérations Block_copy et Block_release lorsque le bloc traverse la frontière. Si le code Objective-C stocke le bloc dans une variable d'instance, l'intégration de ARC de Swift s'assure que les références Swift capturées sont maintenues. Ces références sont libérées lorsque le titulaire Objective-C libère le bloc, empêchant l'utilisation après libération tout en évitant la gestion manuelle de la conservation.
Qu'est-ce qui distingue la disposition mémoire d'un type de fonction @convention(c) d'une référence de fermeture Swift standard ?
Une fermeture Swift standard est un objet du tas comptant les références ou une paire de contextes allouée sur la pile qui peut capturer des variables. En revanche, un type de fonction @convention(c) se compile en un seul mot machine représentant une adresse de fonction brute. Il n'a pas de métadonnées associées, de comptes de maintien ou de contexte de capture. Cette distinction signifie que tandis que les fermetures Swift standard peuvent dispatcher dynamiquement et gérer la mémoire, les fermetures @convention(c) sont des adresses statiques nécessitant des paramètres de contexte explicites UnsafeMutableRawPointer.