QNativeIpcKey Class

Description détaillée

Les classes ` QSharedMemory ` et ` QSystemSemaphore ` identifient leurs ressources à l'aide d'un identifiant système appelé « clé ». La valeur de clé de bas niveau ainsi que le type de clé sont encapsulés dans Qt à l'aide de la classe ` QNativeIpcKey `.

Ces deux classes fournissent également les moyens de créer des clés natives à partir d’un identifiant multiplateforme, à l’aide de QSharedMemory::platformSafeKey() et QSystemSemaphore::platformSafeKey(). Les applications ne doivent en aucun cas partager les données d’entrée de ces fonctions, car différentes versions de Qt peuvent effectuer des transformations différentes, ce qui aboutit à des clés natives différentes. Au lieu de cela, l’application ayant créé l’objet IPC doit communiquer la clé native obtenue à l’aide des méthodes décrites ci-dessous.

Pour plus de détails sur les types de clés, les limitations spécifiques à chaque plateforme et l’interopérabilité avec des applications plus anciennes ou non Qt, consultez la documentation sur les clés IPC natives. Celle-ci contient des informations importantes pour les applications en sandbox sur les plateformes Apple, y compris toutes les applications obtenues via l’App Store d’Apple.

Transmission des clés à d’autres processus

Communication des clés à d’autres processus Qt

Si l’autre processus prend en charge `QNativeIpcKey`, la meilleure méthode de communication consiste à utiliser la représentation sous forme de chaîne obtenue via ` toString()` et à l’analyser à l’aide de ` fromString()`. Cette représentation peut être stockée dans un fichier dont le nom est bien connu ou transmise en ligne de commande à un processus enfant via ` QProcess::setArguments()`.

Si l’autre processus ne prend pas en charge QNativeIpcKey, les deux processus peuvent alors échanger la valeur obtenue par nativeKey(), mais l’ancien code ne sera probablement pas en mesure d’adapter son type de clé. La fonction ` legacyDefaultTypeForOs()` renvoie le type utilisé par le code hérité, qui peut ne pas correspondre à la constante ` DefaultTypeForOs `. Cela reste vrai même si l’ancienne application n’utilise pas la même version que la nouvelle (par exemple, s’il s’agit d’une application Qt 5), à condition que les options passées au script de configuration Qt soient identiques.

Communication des clés à des processus non-Qt

Lorsqu’elle communique avec des processus non-Qt, l’application doit s’assurer d’obtenir le type de clé utilisé par l’autre processus. Ceci est particulièrement important sur les systèmes Unix, où les formats PosixRealtime et SystemV sont courants.

Représentation sous forme de chaîne des clés natives

Le format de la représentation sous forme de chaîne d’un `QNativeIpcKey` est censé être stable et donc compatible en amont et en aval, à condition que le type de clé soit pris en charge par la version de Qt en question. Autrement dit, une version antérieure de Qt ne parviendra pas à analyser la représentation sous forme de chaîne d’un type de clé introduit après sa sortie. Cependant, le fait de parvenir à analyser une représentation sous forme de chaîne n’implique pas que les classes Qt puissent créer avec succès un objet de ce type ; les applications doivent vérifier la prise en charge à l’aide de QSharedMemory::isKeyTypeSupported() et QSystemSemaphore::isKeyTypeSupported().

Le format de la représentation sous forme de chaîne est constitué de deux composants, séparés par deux points (':'). Le premier composant est le type de clé, décrit dans le tableau ci-dessous. Le second composant est une charge utile spécifique au type, utilisant percent-encoding. Pour tous les types de clés actuellement pris en charge, la forme décodée est identique au contenu du champ nativeKey().

Ce format ressemble à un URI et permet l’analyse à l’aide de fonctions d’analyse d’URI/URL, telles que QUrl. Lorsqu’il est analysé par une telle API, le type de clé apparaîtra sous la forme scheme, et la charge utile sera path. L’utilisation de requêtes ou de fragments est réservée.