QNativeIpcKey Class

Detaillierte Beschreibung

Die Klassen QSharedMemory und QSystemSemaphore identifizieren ihre Ressource mit einem systemweiten Bezeichner, dem "Schlüssel". Der Low-Level-Schlüsselwert sowie der Schlüsseltyp werden in Qt mit der Klasse QNativeIpcKey gekapselt.

Diese beiden Klassen bieten auch die Möglichkeit, mit QSharedMemory::platformSafeKey() und QSystemSemaphore::platformSafeKey() native Schlüssel aus einem plattformübergreifenden Bezeichner zu erzeugen. Anwendungen sollten niemals die Eingabe für diese Funktionen gemeinsam nutzen, da verschiedene Versionen von Qt unterschiedliche Transformationen durchführen können, was zu unterschiedlichen nativen Schlüsseln führt. Stattdessen sollte die Anwendung, die das IPC-Objekt erstellt hat, den resultierenden nativen Schlüssel mit Hilfe der unten beschriebenen Methoden mitteilen.

Details zu den Schlüsseltypen, plattformspezifischen Einschränkungen und der Interoperabilität mit älteren oder Nicht-Qt-Anwendungen finden Sie in der Dokumentation Native IPC Keys. Diese enthält wichtige Informationen für Sandbox-Anwendungen auf Apple-Plattformen, einschließlich aller Anwendungen, die über den Apple App Store bezogen werden.

Kommunikation von Schlüsseln mit anderen Prozessen

Übermittlung von Schlüsseln an andere Qt-Prozesse

Wenn der andere Prozess QNativeIpcKey unterstützt, ist der beste Weg der Kommunikation über die String-Repräsentation, die man von toString() erhält und mit fromString() parst. Diese Repräsentation kann in einer Datei gespeichert werden, deren Name bekannt ist, oder auf der Kommandozeile an einen Kindprozess mit QProcess::setArguments() übergeben werden.

Wenn der andere Prozess QNativeIpcKey nicht unterstützt, können die beiden Prozesse die nativeKey() austauschen, aber der ältere Code ist wahrscheinlich nicht in der Lage, seinen Schlüsseltyp anzupassen. Die Funktion legacyDefaultTypeForOs() gibt den Typ zurück, den der alte Code verwendet hat, der möglicherweise nicht mit der Konstante DefaultTypeForOs übereinstimmt. Dies gilt auch dann, wenn die alte Anwendung nicht den gleichen Build wie die neue verwendet (z.B. eine Qt 5 Anwendung), vorausgesetzt, die an das Qt configure Skript übergebenen Optionen sind die gleichen.

Kommunikation von Schlüsseln mit Nicht-Qt-Prozessen

Bei der Kommunikation mit Nicht-Qt-Prozessen muss die Anwendung dafür sorgen, dass sie den Schlüsseltyp erhält, den der andere Prozess verwendet. Dies ist besonders auf Unix-Systemen wichtig, wo sowohl PosixRealtime als auch SystemV üblich sind.

String-Darstellung von nativen Schlüsseln

Das Format der String-Repräsentation eines QNativeIpcKey soll stabil und daher rückwärts- und vorwärtskompatibel sein, vorausgesetzt der Schlüsseltyp wird von der betreffenden Qt-Version unterstützt. Das bedeutet, dass ein älteres Qt die String-Repräsentation eines Schlüsseltyps, der erst nach seiner Veröffentlichung eingeführt wurde, nicht parsen kann. Das erfolgreiche Parsen einer String-Repräsentation bedeutet jedoch nicht, dass die Qt-Klassen erfolgreich ein Objekt dieses Typs erstellen können; Anwendungen sollten die Unterstützung mit QSharedMemory::isKeyTypeSupported() und QSystemSemaphore::isKeyTypeSupported() überprüfen.

Das Format der String-Darstellung besteht aus zwei Komponenten, die durch einen Doppelpunkt (':') getrennt sind. Die erste Komponente ist der Schlüsseltyp, der in der folgenden Tabelle beschrieben wird. Die zweite Komponente ist eine typspezifische Nutzlast, die percent-encoding verwendet. Für alle derzeit unterstützten Schlüsseltypen ist die entschlüsselte Form identisch mit dem Inhalt des Feldes nativeKey().

Dieses Format ähnelt einem URI und ermöglicht das Parsen mit URI/URL-Parsing-Funktionen wie QUrl. Wenn es von einer solchen API geparst wird, erscheint der Schlüsseltyp als scheme und die Nutzlast als path. Die Verwendung von Abfragen oder Fragmenten ist vorbehalten.