Qt documentation states that it is possible to connect two signals together:
It is even possible to connect a signal directly to another signal.
I tried:
connect(x, SIGNAL(S()), y, SIGNAL(func()));
and it works as mentioned, but Qt documentation continues:
(This will emit the second signal immediately whenever the first is emitted.)
Does this mean that QueuedConnection will not work correctly? Can I connect two signals across threads?
The reason I am asking this is because I solved a class of crashes on an application by avoiding this, but I am not sure if this was related to connecting signals together.
Queued Connection The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread. Blocking Queued Connection The slot is invoked as for the Queued Connection, except the current thread blocks until the slot returns.
This ensures that truly independent components can be created with Qt. You can connect as many signals as you want to a single slot, and a signal can be connected to as many slots as you need. It is even possible to connect a signal directly to another signal.
It shouldn't be a great deal different from a signal/slot connection. Let's take a look at underlying mechanism of signals/slots. There is an event queue in each thread which maintains signals (events) that have been emitted but not processed yet. So whenever the execution returns to the event loop the queue is processed. Event loop itself doesn't handle the events. Rather it delivers them to the objects so they can handle it. In this special case, I suppose that the object would emit another signal which would be inserted in the queue. When the execution returns to event loop the new signal is handled by the object again. Here is a test which proves the above argument.
If you run the codes attached, the output would be:
before signal() after signal() slot() called
which means defining a signal-signal connection type as queued between threads have the expected queued behaviour, that rejects the argument which it is always immediate. If you define it as direct, the output would be:
before signal() slot() called after signal()
as expected. it doesn't generate any errors or warnings, and program doesn't crash as well.Yet this simple example doesn't prove it works for a large and complex one as well.
main.cpp:
#include <QtGui/QApplication> #include "dialog.h" #include "testssconnection.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); TestSignalSignalConnection * t = new TestSignalSignalConnection(); t->start(); return a.exec(); }
testssconnection.h:
#ifndef TESTSSCONNECTION_H #define TESTSSCONNECTION_H #include <QObject> #include <QThread> class TestSignalSignalConnection : public QThread { Q_OBJECT public: explicit TestSignalSignalConnection(QObject *parent = 0); void run(); signals: void signal1(); void signal2(); public slots: void slot(); }; #endif // TESTSSCONNECTION_H
testssconnection.cpp:
#include "testssconnection.h" #include <QtCore> TestSignalSignalConnection::TestSignalSignalConnection(QObject *parent) : QThread(parent) { } void TestSignalSignalConnection::run() { TestSignalSignalConnection *t = new TestSignalSignalConnection(); this->connect(this,SIGNAL(signal1()),t,SIGNAL(signal2()), Qt::QueuedConnection); t->connect(t,SIGNAL(signal2()), t,SLOT(slot()), Qt::DirectConnection); qDebug() << "before signal()"; emit signal1(); qDebug() << "after signal()"; exec(); } void TestSignalSignalConnection::slot() { qDebug() << "slot() called"; }
Take a look at qt-project, its a great wiki page about Threads and signals.
Threads, Events and QObjects::Signals and slots across threads
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With