为什么执行socket :: readyRead()的新信号,即使它的早期插槽仍处理？

Question

根据以下帖子,仅在当前正在执行的时隙完成时才提供发出的信号.
等待SLOT用Qt完成执行

我有一个基于ssl socket的客户端 - 服务器通信应用程序,它是单线程的.

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

客户端和服务器互相发送一些自定义消息.无论何时发送或接收消息,它们都发送ACK字节(00).
大多数时候,我注意到当处于Read()执行之间时,下一个readyRead()服务!我把调试语句放在开头和结尾myObject->Read().他们确认,开始调试再次被调用.断点也观察到相同的情况.

当接收到太多数据时,会创建一个递归堆栈帧太多的Read()s.它要么减慢app GUI的速度,要么崩溃.
通常,当客户端尝试发送ACK作为其一部分时,会发生此递归myObject->Read().在此期间readyRead()偶然发出信号并获得服务.但是,之前信号的插槽仍在处理中.

问题:

• 当插槽还处于中间位置(单线程)时,Qt框架是否有可能在两者之间提供信号？
• 如何修复此套接字特定方案？

注:
-默认情况下为单一线程,Qt::ConnectionType是DirectConnection.我也尝试过QueuedConnection,但结果是一样的.
- myObject.Read()非常复杂,还有许多其他函数调用.如果这导致问题,那么让我知道我应该寻找什么.编写它的实际代码是不切实际的.

Answer 1

readyRead()由于事件循环在其间被释放，因此发生了递归调用。以下函数导致事件循环被释放：

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

第一个是可以理解的，因为它就是为了这个目的。但第二次flush()完全出乎意料。它的文档没有这样说明。至少在我的调试中，它表明，每当flush()调用 时，都会调用并满足后续操作readyRead()。在 Qn 中也可以看到这一点。

其processEvent()目的是使 GUI 在数据高负载期间更具响应性。但似乎，我们也需要做出另一种选择。