QNativeIpcKey Class

詳細な説明

QSharedMemory クラスおよびQSystemSemaphore クラスは、「キー」と呼ばれるシステム全体の識別子を使用してリソースを識別します。低レベルのキー値およびキーの型は、QNativeIpcKey クラスを使用して Qt 内でカプセル化されています。

また、これら 2 つのクラスは、QSharedMemory::platformSafeKey() および QSystemSemaphore::platformSafeKey() を使用して、クロスプラットフォームの識別子からネイティブキーを作成する手段も提供しています。Qt のバージョンによって変換処理が異なり、結果として異なるネイティブキーが生成される可能性があるため、アプリケーションはこれらの関数への入力を決して共有してはなりません。 その代わりに、IPC オブジェクトを作成したアプリケーションは、以下で説明する手法を用いて、生成されたネイティブキーを通達する必要があります。

キーの種類、プラットフォーム固有の制限、および古いアプリケーションや非 Qt アプリケーションとの相互運用性に関する詳細については、「ネイティブ IPC キー」のドキュメントを参照してください。これには、Apple App Store を通じて入手したすべてのアプリを含む、Apple プラットフォーム上のサンドボックス化されたアプリケーションに関する重要な情報が含まれています。

他のプロセスへのキーの伝達

他の Qt プロセスへのキーの伝達

相手側のプロセスが QNativeIpcKey をサポートしている場合、通信を行う最善の方法は、toString() から取得した文字列表現を使用し、fromString() を使用してそれを解析することです。この表現は、よく知られた名前のファイルに保存したり、QProcess::setArguments() を使用してコマンドラインから子プロセスに渡したりすることができます。

もし相手側のプロセスが QNativeIpcKey をサポートしていない場合、2 つのプロセスはnativeKey() を交換することはできますが、古いコードではキーの型を調整できない可能性が高いです。legacyDefaultTypeForOs() 関数は、レガシーコードで使用されていた型を返しますが、これはDefaultTypeForOs 定数と一致しない場合があります。これは、古いアプリケーションが新しいアプリケーションと同じビルドを使用していない場合（たとえば、Qt 5 アプリケーションである場合）でも、Qt の configure スクリプトに渡されるオプションが同じであれば当てはまります。

Qt以外のプロセスへのキーの伝達

Qt以外のプロセスと通信する場合、アプリケーションは相手プロセスが使用しているキーの型を取得するよう手配する必要があります。これは特に、PosixRealtime とSystemV の両方が一般的であるUnixシステムにおいて重要です。

ネイティブキーの文字列表現

QNativeIpcKey の文字列表現の形式は安定していることを意図しており、したがって、当該キータイプが対象の Qt バージョンでサポートされている限り、後方互換性および前方互換性が保たれます。つまり、古いバージョンの Qt では、そのリリース後に導入されたキータイプの文字列表現を解析できないことになります。 ただし、文字列表現の解析に成功したからといって、Qt クラスがその型のオブジェクトを正常に作成できるとは限りません。アプリケーションでは、QSharedMemory::isKeyTypeSupported() および QSystemSemaphore::isKeyTypeSupported() を使用して、サポート状況を検証する必要があります。

文字列表現の形式は、コロン (':') で区切られた 2 つの構成要素から成ります。最初の構成要素は、以下の表に示すキー型です。2 番目の構成要素は、percent-encoding を使用した型固有のペイロードです。現在サポートされているすべてのキー型について、デコード後の形式はnativeKey() フィールドの内容と同一です。

この形式はURIに似ており、QUrl などのURI/URL解析関数を使用して解析することができます。このようなAPIで解析された場合、キータイプはscheme として表示され、ペイロードはpath となります。クエリやフラグメントの使用は予約されています。