QNativeIpcKey Class

Ausführliche Beschreibung

Die Klassen „ QSharedMemory “ und „ QSystemSemaphore “ identifizieren ihre Ressource mithilfe eines systemweiten Bezeichners, der als „Schlüssel“ bezeichnet wird. Der Low-Level-Schlüsselwert sowie der Schlüsseltyp werden in Qt mithilfe der Klasse „ QNativeIpcKey “ gekapselt.

Diese beiden Klassen bieten zudem die Möglichkeit, mithilfe von `QSharedMemory::platformSafeKey()` und `QSystemSemaphore::platformSafeKey()` native Schlüssel aus einer plattformübergreifenden Kennung zu erstellen. Anwendungen sollten die Eingaben für diese Funktionen niemals 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 mithilfe der unten beschriebenen Methoden übermitteln.

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

Übermittlung von Schlüsseln an andere Prozesse

Weitergabe von Schlüsseln an andere Qt-Prozesse

Wenn der andere Prozess `QNativeIpcKey` unterstützt, erfolgt die Kommunikation am besten über die Zeichenfolgendarstellung, die mit ` toString()` abgerufen und mit ` fromString()` geparst wird. Diese Darstellung kann in einer Datei mit bekanntem Namen gespeichert oder über die Befehlszeile mithilfe von ` QProcess::setArguments()` an einen untergeordneten Prozess übergeben werden.

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

Weitergabe von Schlüsseln an Nicht-Qt-Prozesse

Bei der Kommunikation mit Nicht-Qt-Prozessen muss die Anwendung dafür sorgen, dass sie den vom anderen Prozess verwendeten Schlüsseltyp ermittelt. Dies ist insbesondere auf Unix-Systemen wichtig, auf denen sowohl PosixRealtime als auch SystemV üblich sind.

Zeichenkettendarstellung nativer Schlüssel

Das Format der Zeichenfolgendarstellung eines `QNativeIpcKey` ist als stabil und somit vorwärts- und rückwärtskompatibel gedacht, sofern der Schlüsseltyp von der betreffenden Qt-Version unterstützt wird. Das heißt, eine ältere Qt-Version kann die Zeichenfolgendarstellung eines Schlüsseltyps, der nach ihrer Veröffentlichung eingeführt wurde, nicht analysieren. Das erfolgreiche Parsen einer Zeichenfolgendarstellung bedeutet jedoch nicht, dass die Qt-Klassen ein Objekt dieses Typs erfolgreich erstellen können; Anwendungen sollten die Unterstützung mithilfe von QSharedMemory::isKeyTypeSupported() und QSystemSemaphore::isKeyTypeSupported() überprüfen.

Das Format der Zeichenfolgendarstellung besteht aus zwei durch einen Doppelpunkt (':') getrennten Komponenten. 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. Bei allen derzeit unterstützten Schlüsseltypen entspricht die dekodierte Form dem Inhalt des Feldes „ nativeKey()“.

Dieses Format ähnelt einer URI und ermöglicht das Parsen mit URI-/URL-Parsing-Funktionen wie QUrl. Beim Parsen durch eine solche API wird der Schlüsseltyp als scheme angezeigt, und die Nutzdaten lauten path. Die Verwendung von Abfragen oder Fragmenten ist reserviert.