QNativeIpcKey Class

Description détaillée

Les classes QSharedMemory et QSystemSemaphore identifient leur ressource à l'aide d'un identifiant à l'échelle du système appelé "clé". La valeur de la clé de bas niveau ainsi que le type de clé sont encapsulés dans Qt XML à 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, en utilisant QSharedMemory::platformSafeKey() et QSystemSemaphore::platformSafeKey(). Les applications ne doivent jamais partager l'entrée de ces fonctions, car les différentes versions de Qt peuvent effectuer des transformations différentes, ce qui se traduit par des clés natives différentes. Au lieu de cela, l'application qui a créé l'objet IPC doit communiquer la clé native résultante à l'aide des méthodes décrites ci-dessous.

Pour plus de détails sur les types de clés, les limitations spécifiques aux plates-formes et l'interopérabilité avec des applications plus anciennes ou non Qt, voir la documentation sur les clés IPC natives. Cela inclut des informations importantes pour les applications en bac à sable sur les plateformes Apple, y compris toutes les applications obtenues via l'App Store d'Apple.

Communiquer des clés à d'autres processus

Communiquer des clés à d'autres processus Qt

Si l'autre processus prend en charge QNativeIpcKey, la meilleure façon de communiquer est d'utiliser la représentation sous forme de chaîne de caractères obtenue à partir de toString() et de l'analyser à l'aide de fromString(). Cette représentation peut être stockée dans un fichier dont le nom est bien connu ou transmise sur la ligne de commande à un processus enfant en utilisant QProcess::setArguments().

Si l'autre processus ne prend pas en charge QNativeIpcKey, les deux processus peuvent échanger la fonction nativeKey(), mais le code le plus ancien sera probablement incapable d'ajuster son type de clé. La fonction legacyDefaultTypeForOs() renvoie le type utilisé par l'ancien code, 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 transmises au script Qt configure soient les mêmes.

Communiquer des clés à des processus non-Qt

Lors de la communication avec des processus non-Qt, l'application doit s'arranger pour obtenir le type de clé utilisé par l'autre processus. Ceci est particulièrement important sur les systèmes Unix, où les clés PosixRealtime et SystemV sont courantes.

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

Le format de la représentation en chaîne d'une 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. En d'autres termes, une version plus ancienne 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 d'analyser avec succès une représentation sous forme de chaîne ne signifie pas que les classes Qt peuvent créer avec succès un objet de ce type ; les applications doivent vérifier la prise en charge en utilisant QSharedMemory::isKeyTypeSupported() et QSystemSemaphore::isKeyTypeSupported().

Le format de la représentation de la chaîne est formé 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 deuxième élément 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 peut être analysé à l'aide de fonctions d'analyse 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 sous la forme path. L'utilisation d'une requête ou de fragments est réservée.