2012-06-27 5 views
5

私は作業しているソースコードを掘り下げていました。私は誰かがコード化したという独特の声明を見つけました。ソースコードは、QML GUIを備えたGUIアプリケーションであり、QT 4.7.xを使用します。QObjectベースのクラスは、自分自身へのキューに接続されています

以下のスニペットは、コアアプリケーションロジックに属しています。

// connect signal-slots for decoupling 
QObject::connect (this, SIGNAL(setCurrentTaskSignal(int)), this, 
    SLOT(SetCurrentTaskSlot(int)), Qt::QueuedConnection); 

これは、オブジェクトが、基本的にオブジェクトが同時に異なるスレッドで「生きる」ことを意味キューに入れられた接続を介して自身に接続されていることを奇妙ですか?

一見私には意味がありませんでした。なぜこのような接続が妥当か必要かという何らかの理由を考える人はいますか?これは機能するでしょうか?

答えて

9

問題なく動作します。たぶん、SetCurrentTaskSlotを呼び出す前にイベントループ処理が必要なのでしょうか?

QueuedConnectionは、何かが別のスレッドにあることを意味するものではありません。 QueuedConnectionは、シグナルが発信されたときに、対応するスロットが直接呼び出されないことを意味します。イベントループでキューに入れられ、制御がイベントループに戻されるときに処理されます。

+0

意味があります。私はまだコードを取り巻くものを見ています。だから、私は何が起きているのか分かりました。 –

+1

これは、何らかの計算を実行している間にタスク変更信号が出力され、すぐには「変更」が起こらないように見えますが、現在のフローが実行されてイベント処理が再開した後です。 –

3

キューに登録されている接続は、受信者がどこに住んでいるかについては何も意味しません。逆のことが言えます。別のスレッドにあるオブジェクトに安全に信号を送るには、キューに入れられた接続を使用する必要があります。しかし、あなたはどのスレッドにも存在するオブジェクトのためにそれらを使うことができます!

1つは、信号がイベントループ内から配信され、直接接続で発生するようにemitサイトから即座に配信されないようにするために、キュー接続を使用します。直接接続は、概念的には、リスト上の関数ポインタへの呼び出しの集合です。キュー接続は、概念的には、イベントの内容に基づいて関数呼び出しを実行できる巧妙な受信者に送信されるイベントです。

イベントは内部QMetaCallEventであり、このイベントに応じて動作し、コールを実行します。このイベントはQObject::eventです。

関連する問題