Order of execution if a slot is called twice by the same signal

RLocksley

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 signal decryptPacket(QByteArray& packet).
The onDecryptPacket(QByteArray& packet) slot decrypts the packet and then emits another signal processPacket(QByteArray& decryptedPacket).
The packets can be very different in size, so the runtime of onDecryptPacket() can be very different.
Because the size of the packets can be large I have to call processEvent() inside onDecryptPacket() and onProcessPacket().

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 if onDecryptPacket(packetA) takes so long, that in the mean time onReadyRead() emits decryptPacket(packetB) and onDecryptPacket(packetB) emits processPacket(decryptedPacketB) before onDecryptPacket(packetA) emits processPacket(decryptedPacketA)?
It seems to be possible because of the processEvent() calls.

Does a standard way exist, which avoids a freezing UI and ensures that processPacket(decryptedPacketA) is emitted before processPacket(decryptedPacketB)?

jsulm

@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.

J.Hilk

@RLocksley

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

@J-Hilk @jsulm Thank you for the answers. I edited my question.

J.Hilk

@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.html

and I'll link you to my GitHub page, where I have an example use case of all common Qt ways
https://github.com/DeiVadder/QtThreadExample

since you do most function calls already via Signals, it should be easy to move to a Qt threading method