c++ - 为什么执行 socket::readyRead() 的新信号，即使其较早的插槽仍在处理中？

Question

根据以下帖子，只有在当前正在执行的插槽完成后，才会提供发出的信号。
Wait for a SLOT to finish the execution with Qt

我有一个基于 ssl 套接字的客户端-服务器通信应用程序，它是单线程的。

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

客户端和服务器互相发送一些自定义消息。无论何时发送或接收消息，它们都会发送 ACK 字节 (00)。
大多数时候，我注意到当 Read() 处于执行之间时，会提供下一个 readyRead()!我将调试语句放在 myObject->Read() 的开头和结尾。他们确认，开始调试被一次又一次地调用。断点也是如此。

当接收到太多数据时，会创建一个包含太多 Read() 的递归堆栈帧。它要么会降低应用程序 GUI 的速度，要么会导致崩溃。
通常，当客户端尝试将 ACK 作为 myObject->Read() 的一部分发送时，就会发生这种递归。在此期间，readyRead() 偶然发出信号并得到服务。但是之前信号的槽还在处理中。

问题:

• Qt 框架是否有可能在插槽仍处于中途(单线程)时提供信号？
• 如何解决此套接字特定情况？

注意:
- 默认情况下，对于单线程，Qt::ConnectionType 是 DirectConnection。我也尝试过 QueuedConnection，但结果是一样的。
- myObject.Read() 非常复杂并且有许多其他函数调用。如果这是导致问题的原因，请告诉我应该寻找什么。编写它的实际代码是不切实际的。

Answer 1

readyRead() 的递归调用之所以发生，是因为事件循环在两者之间被释放了。以下函数导致事件循环被释放:

1. QCoreApplication::processEvents()
2. SslSocket::flush()

第一个是可以理解的，因为它就是为此而生的。但是第二个 flush() 完全出乎意料。它的documentation没有这么说。至少在我的调试中它表明，每当 flush() 被调用时，随后的 readyRead() 就会被调用和满足。在 Qn 中也可以看到这一点。

processEvent() 旨在使 GUI 在数据高加载期间响应更快。但看来，同样的事情，我们还需要另作选择。