Qt Signal Slot Connection Type
Connect(this,SIGNAL(pushclient(QTcpSocket.,qintptr)),this,SLOT(clientList(QTcpSocket.,qintptr)),Qt::DirectConnection); will also be called in this 's thread. The connection type has little relevance to normal code, as the emitter and receiver are one and the same and the default expands to DirectConnection anyway (see below case 2 for when it's. QtCore.SIGNAL and QtCore.SLOT macros allow Python to interface with Qt signal and slot delivery mechanisms. This is the old way of using signals and slots. The example below uses the well known clicked signal from a QPushButton. The connect method has a non python-friendly syntax. It is necessary to inform the object, its signal (via macro) and a slot to be connected to. QtPrivate:: QSlotObjectBase.slotObj = new QtPrivate:: QSlotObject::Value, typename SignalType::ReturnType(slot); return connectImpl(sender, reinterpretcast(& signal), receiver, reinterpretcast(& slot), slotObj, type, types, & SignalType::Object::staticMetaObject);.
- In the upcoming Qt5, an alternative syntax exist. The former syntax will still work. But you can now also use this new way of connecting your signals to your slots: connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue ); Which one is the more beautiful is a matter of taste. One can quickly get used to the new syntax.
- Qt::AutoConnection (Default) If the receiver lives in the thread that emits the signal, Qt::DirectConnection is used. Otherwise, Qt::QueuedConnection is used. The connection type is determined when the signal is emitted.
Example
Some times you see a signal is emitted in sender thread but connected slot doesn't called (in other words it doesn't receive signal), you have asked about it and finaly got that the connection type Qt::DirectConnection would fix it, so the problem found and everything is ok.
But generaly this is bad idea to use Qt:DirectConnection until you really know what is this and there is no other way. Lets explain it more, Each thread created by Qt (including main thread and new threads created by QThread) have Event loop, the event loop is responsible for receiving signals and call aproporiate slots in its thread. Generaly executing a blocking operation inside an slot is bad practice, because it blocks the event loop of that threads so no other slots would be called.
If you block an event loop (by making very time consuming or blocking operation) you will not receive events on that thread until the event loop will be unblocked. If the blocking operation, blocks the event loop forever (such as busy while), the slots could never be called.
In this situation you may set the connection type in connect to Qt::DirectConnection, now the slots will be called even the event loop is blocked. so how this could make broke everything? In Qt::DirectConnection Slots will be called in emiter threads, and not receiver threads and it can broke data synchronizations and ran into other problems. So never use Qt::DirectConnection unless you know what are you doing. If your problem will be solved by using Qt::DirectConnection, you have to carefull and look at your code and finding out why your event loop is blocked. Its not a good idea to block the event loop and its not recomended in Qt.
Here is small example which shows the problem, as you can see the nonBlockingSlot would be called even the blockingSlot blocked event loop with while(1) which indicates bad coding
