2012-05-01 5 views
0

JUCEベースのマルチスレッドOpenGLアプリケーションの3つのインスタンスを1台のマシンで実行しています。各インスタンスは別々のXディスプレイに接続されています。メインのアプリケーションスレッドは、XInitThreadsとそれに続いてXOpenDisplayを適切なディスプレイに呼び出します。主レンダリングループには別のスレッドが使用されます。アプリケーションの3つのインスタンスが互いに初期化されるため、次回の起動時にグラフィックス設定が完了します。複数のマルチスレッドLinux OpenGLアプリケーションでglXMakeCurrentが返さない

80%のケースではすべてが正常に起動しますが、アプリケーションの2番目および/または3番目のインスタンスでは、glXMakeCurrentの4番目の呼び出し(これは第1回目と同じものです接続が初期化された)返されません。 Xスレッドが初期化され、スレッドがロックを使用していて、glXMakeCurrentの呼び出しの直前にXディスプレイがXLockDisplayでロックされています(呼び出しが戻った後はロック解除されます)。

各アプリケーションが正しい表示&コンテキストを使用していることを確認しました。純粋に、同じディスプレイ接続にアクセスする複数のスレッドの問題に関連していた場合、最初のインスタンスがこの問題に遭遇する可能性も同じです。

glXMakeCurrentはXディスプレイへの排他的アクセス権を持っていますが、なぜ返されないのでしょうか?

答えて

0

実際、私は間違っていました。問題は、JUCE OpenGLコンテキストのロックがないことが原因であるように思われます。したがって、Xディスプレイ・ロックは正しく取得されましたが、マップされるはずのコンテキストは、問題の場合は別のスレッドによって同時にアクセスされ、glXMakeCurrentがデッドロックする原因になっていました。

関連する問題