Ich bin mir nicht sicher über die Art des Signal/Slot-Mechanismus in Qt 4.5. Wenn ein Signal ausgesendet wird, ist es ein blockierender Funktionsaufruf oder ein Thread? Sagen Sie diesQt 4.5 - Sendet Signal einen Funktionsaufruf oder einen Thread, und blockiert es?
Wird die gesamte Signal-/Slot-Kette aufgelöst, bevor mit der nächsten Zeile fortgefahren wird?
Kommt drauf an. Von der documentation:
:Wenn ein Signal ausgegeben wird, werden die mit ihm verbundenen Steckplätze normalerweise sofort ausgeführt, genau wie bei einem normalen Funktionsaufruf. Wenn dies geschieht, ist der Mechanismus für Signale und Schlitze völlig unabhängig von einer GUI-Ereignisschleife. Die Ausführung des Codes nach der
emit-Anweisung erfolgt, sobald alle Steckplätze zurückgegeben wurden. Bei Verwendung von queued connections ist die Situation etwas anders; In einem solchen Fall wird der Code, der dem Schlüsselwort emit folgt, sofort fortgesetzt, und die Slots werden später ausgeführt.
So in normalen Fällen wird es synchron und blockiert sein und mit Verbindungen in Warteschlange wird asynchron und nicht blockierend sein.
laaltos Antwort ist korrekt. Ein weiterer Punkt: Wenn alle Ihre QObjects zum selben Thread gehören und Sie nicht in der Warteschlange eingereihte Verbindungen angegeben haben, dann erfolgt die Ausführung der mit dem Signal verbundenen Slots synchron - die gesamte Verarbeitung wird vor der nächsten Zeile nach dem 'emit ausgeführt ' Erklärung. Da dies der häufigste Fall ist, lautet die Antwort auf Ihre Frage normalerweise "Ja". Die Dokumentation zu signals and slots across multiple threads kann hilfreich für Sie sein.
Das größte Problem ist, dass Sie einfach nicht wissen können. Das heißt, wenn Sie aus der Sicht der Klasse schauen. Wenn Sie emittieren, wissen Sie nicht, was passieren wird:
Es wird noch schwieriger zu wissen, was passieren wird, wenn mehrere Objekte mit dem Internet verbunden sind Signal. In diesem Fall könnten einige Slots ausgeführt worden sein, während andere noch in der Warteschlange stehen. Es ist übrigens kein Thread mit einer nicht blockierenden Verbindung beteiligt. Es gibt nur ein Ereignis, das in der Ereignisschleife des Threads des empfangenden Objekts gepostet wird.
Beachten Sie auch, dass standardmäßig Verbindungen zwischen Objekten im selben Thread direkt (synchron) sind und Verbindungen zwischen Objekten in verschiedenen Threads in die Warteschlange gestellt werden. Wenn Sie darüber nachdenken, ist das ziemlich logisch. – quark
@quark Das stimmt nicht genau. Es spielt keine Rolle, ob sich die Objekte im selben Thread befinden oder nicht. Es spielt eine Rolle, ob der Thread, der das Signal ausgibt, der Thread ist, in dem sich das empfangende Objekt befindet. Die Qt-Dokumentation hat das sogar falsch verstanden.Quelle: [Signale und Slots über Threads] (http://qt-project.org/wiki/Threads_Events_QObjects#913fb94dd61f1a62fc809f8d842c3afa). Ich stimme zu, dass das Verhalten von Qt logisch ist. –