2

現在Qt 以外のアプリケーションでQt クラスを再利用したいので、Qtをライブラリとして使用しようとしています。すべてが非 GUI です。

一部の問題はDirectConnectionで簡単に回避できます。一部の問題はプライベート イベント ループで解決できます。スレッドで偽のQCoreApplicationを実行して動作させることもできます (最後の手段)。

どのモジュールがQCoreApplicationの実行中のインスタンスに依存しており、それなしでは機能しないかを知りたいです。

一部の Qt モジュール ( QtCore内)を正しく実行するには、 QCoreApplicationのインスタンスが必要です。たとえば、QTimerはQCoreApplicationに依存してタイマー イベントをディスパッチします。私はQtConcurrentRunのドキュメントを読んでいましたが、 QThreadPoolのグローバル インスタンスに依存しているようです。アプリケーションの実行が重要かどうか、または最初のアクセスでインスタンスが作成されるかどうかを確認しようとしています。

QCoreApplicationPrivateソース (今のところ Windows と Linux)を研究するつもりですが、正しい方向へのヒントは大歓迎です。

コア アプリケーションに対する他の機能の依存関係は何ですか? OSによって異なる場合がありますのでご注意ください。

Edit1: Kuba の回答のおかげで、QCoreApplicationイベント ループは、タイマーとソケット イベントをディスパッチする必要がないようです。そのため、一部のQtCoreモジュールではQCoreApplicationのインスタンスが必要ですが、アプリケーション イベント ループを実行する必要はありません。

4

1 に答える 1

3

の存在をQCoreApplication実行中のイベント ループと混同しています。これら 2 つは別の概念です。後者には前者が必要かもしれませんが、後者は前者と同じスレッドで実行する必要はありません。

qApp->exec()特に、 QCoreApplication を構築したスレッドでディスパッチするイベントがない場合は、実際に呼び出す必要はありません。

QCoreApplication の存在は、いわば問題ではありません。事態はさらに複雑になりQApplicationます -- GUI 以外のスレッドで開始できますが、移植性がなく、OS X では動作しません。動作しない理由を理解しようとしていますが、持っていません満足のいく解決策を提供するにはまだ時間がかかりますが、まだです。

また、QCoreApplication のイベント ループは、ソケット通知とタイマー イベントを他のスレッドにディスパッチするために実行する必要があるという誤解です。QCoreApplication のイベント ループは特別なものではありません。そのスレッドで最初の QEventLoop をインスタンス化するときに、そのスレッド用に作成される QAbstractEventDispatcher のプラットフォーム固有のインスタンスがあります。QEventLoop は、プラットフォームに固有のことを何も知りません。

QCoreApplication のexec()メソッドは非常に単純で、QEventLoop のインスタンスを作成するため、プラットフォーム固有の QAbstractEventDispatcher のインスタンスを作成します。このインスタンスは決して特別なものではありません。これまでのところ、コードを読んでわかる限り、他のスレッドで作成された他のイベント ディスパッチャと同じです。

基礎となるすべてのウィンドウ システムがそれをサポートする場合、Qt GUI コードをマルチスレッド化することは実際に可能です。スレッドごとのイベントの受信とディスパッチは、最初の小さなステップとして既に行われています。おそらく唯一の大きな障害は、X ライブラリとそのディスプレイ ロックです。表示ロックは、スレッド間の競合の問題であることは明らかです。GUI と対話したい各スレッドが X サーバーへの個別の接続を開く必要がありますが、Xlib からそれを行う方法がサポートされているかどうかはわかりません。

于 2012-06-06T23:15:23.293 に答える