Why is the new signal for socket :: readyRead () executed even when its previous slot is still being processed?

Question

According to the following publication, an emitted signal is generated only once when the current executable slot is completed.
Wait for SLOT to complete execution with Qt

I have an ssl juice based client-server communication application that is single-threaded.

connect(socket, &QSslSocket::readyRead, [&]() { myObject.Read(); }); 

The client and server send each other some user messages. Whenever a message is sent or received either, they send ACK bytes (00).
In most cases, I notice that when Read() is between execution, the next readyRead() is served! I put the debug statements at the beginning and at the end of myObject->Read() . They confirm that the start of debugging is called again and again. The same is observed at control points.

When too much data is received, the recursive stack stack is created by too many Read() s. This either slows down the application GUI or crashes.
Usually this recursion occurs when a client tries to send an ACK as part of myObject->Read() . During this time, readyRead() indirectly signaled and also serviced. However, the slot of the previous signal was still being processed.

Questions :

• Is it possible for the Qt framework to signal between them when the slot is still in the middle of the path (single stream)?
• How to fix this socket specific scenario?

Note :
- By default, for individual streams, Qt::ConnectionType is DirectConnection . I also tried with QueuedConnection , but the result is the same.
- myObject.Read() is quite complex and has many other function calls. If this causes problems, then let me know what I should look for. Wrong to write the actual code.

Answer 1

The recursive calls to readyRead() were due to the event loop being released between them. The following functions triggered the release of the event loop:

• QCoreApplication::processEvents()
• SslSocket::flush()

The first is understandable, as it is intended for this. But the second flush() was a complete surprise. His documentation did not indicate this. At least in my debugging, it showed that whenever flush() is called, the subsequent readyRead() is called and served. See also in Qn.

processEvent() was supposed to make the GUI more responsive during high data loading. But it looks like we need to make another choice for the same.