4

XInitThreads()メインスレッド以外のスレッドからXサーバーへの呼び出しを実行できるようになることはわかっています。また、Qtを使用してセカンダリスレッドからOpenGL呼び出しを行う場合は、Xlibでの同時スレッドサポートが必要です。私は自分のアプリケーションをそのように必要としていますが、非常にまれな状況です。残念ながら、XInitThreads（）はアプリケーションの実行の最初に呼び出す必要があるため、特定の実行に必要かどうかに影響します（マルチスレッドOpenGLが必要かどうかをアプリを実行する前に知る方法はありません）サポートするかどうか）。

XInitThread（）を無用に呼び出しても、アプリケーションの全体的な動作は変わらないだろうと確信していますが、プログラミングはすべてトレードオフであり、マルチスレッドのサポートがXlibのデフォルトの動作ではない理由があると確信しています。

マニュアルページには、シングルスレッドプログラムがこの関数を呼び出さないことが推奨されていると書かれていますが、その理由は書かれていません。XInitThreads（）を呼び出すときのトレードオフは何ですか？

4

1 に答える 1

13

グローバルロックと各ディスプレイに1つを作成するため、Xlibを呼び出すたびにロック/ロック解除が行われます。代わりに独自のロックを行う場合（独自のロックを使用して一度に1つのスレッドでXlibの使用を維持する）、理論的には、ロックを取得し、一度に多くのXlibを実行してから、ドロップすることで、ロックのオーバーヘッドを減らすことができます。あなたのロック。または、実際には、ほとんどのツールキットは、まったくロックされないモデルを使用しますが、アプリがメインUIスレッドでのみXを使用する必要があるだけです。

多くのXlib呼び出しがブロックしている（サーバーからの応答を待つ）ため、ロックの競合が問題になる可能性があります。

ディスプレイでのXlib呼び出しごとのロックにはセマンティックな問題もあります。スレッドAでの各Xlib呼び出しの間に、理論的には他のXlib呼び出しがスレッドBで行われる可能性があります。したがって、一度に1つだけがXlib要求を行う場合でも、スレッドは表示状態を混乱させるという点で互いに踏みにじることができます。 。つまり、XInitThreads（）は、同時表示アクセスによるクラッシュ/破損を防止していますが、Xサーバー接続を共有する複数のスレッドを持つことのセマンティックな考慮事項を実際には処理していません。

同時表示アクセスから独自のセマンティックな意味を理解する必要があるのは、Xlib呼び出しごとのXInitThreadsロックを気にしない理由の1つだと思います。とにかく、アプリケーションレベルまたはツールキットレベルのロックで終わるためです。

ここでの1つのアプローチは、各スレッドで個別のDisplay接続を開くことです。これは、実行していることによっては意味があります。

もう1つのアプローチは、Xlibではなく新しいxcbAPIを使用することです。xcbは、マルチスレッドでノンブロッキングになるようにゼロから設計されています。

歴史的に、いくつかのOS / XlibバージョンのXInitThreads（）にもいくつかのバグがありましたが、詳細は覚えていませんが、それらが通り過ぎるのを見たことは覚えています。

于 2012-11-13T13:59:21.410 に答える