Order of execution if a slot is called twice by the same signal
-
I have the following situation:
My
onReadyRead()
slot is reading from a TCP socket, collects the payload of TCP-packets until one packet on layer 5, which can be bigger than one TCP packet, is full and then emits a signaldecryptPacket(QByteArray& packet)
.
TheonDecryptPacket(QByteArray& packet)
slot decrypts the packet and then emits another signalprocessPacket(QByteArray& decryptedPacket)
.
The packets can be very different in size, so the runtime ofonDecryptPacket()
can be very different.
Because the size of the packets can be large I have to callprocessEvent()
insideonDecryptPacket()
andonProcessPacket()
.My question:
Let us assume packet A is very large and packet B very small.
Packet A arrives first and Packet B second.
Is it possible that ifonDecryptPacket(packetA)
takes so long, that in the mean timeonReadyRead()
emitsdecryptPacket(packetB)
andonDecryptPacket(packetB)
emitsprocessPacket(decryptedPacketB)
beforeonDecryptPacket(packetA)
emitsprocessPacket(decryptedPacketA)
?
It seems to be possible because of theprocessEvent()
calls.Does a standard way exist, which avoids a freezing UI and ensures that
processPacket(decryptedPacketA)
is emitted beforeprocessPacket(decryptedPacketB)
? -
@RLocksley said in Order of execution if a slot is called twice by the same signal:
Is it possible that if onDecryptPacket(packetA) takes so long, that in the mean time onReadyRead() emits decryptPacket(packetB)
Not if you do not allow the event loop to run (which is normal case when you're executing a slot or something else).
So, in normal case your slots will be executed one after another. -
takes so long
did you sprinkle your code with processEvent() calls so the ui doesn't freeze in your long decrypt phases ?
Because that will case readyRead to be emitted a second time before your slot is finished -
@RLocksley alight,
first of, good that you didn't jump into "threading" right away, its a complicated topic and easy to get wrong.
But the use of processEvents() is not good either :D
in your case you should do your
onDecryptPacket
function in parallel.Qt offers a range of way on how to do that, see
https://doc.qt.io/qt-5/qthread.html
https://doc.qt.io/qt-5/qtconcurrent-index.htmland I'll link you to my GitHub page, where I have an example use case of all common Qt ways
https://github.com/DeiVadder/QtThreadExamplesince you do most function calls already via Signals, it should be easy to move to a Qt threading method