QSerialPort::waitForBytesWritten 带有事件循环的“细微错误”？

Question

在an answer on another question 中，声称当使用带有QSerialPort 的主Qt 事件循环时，QSerialPort::waitForBytesWritten 会导致“细微错误”，因为它会打开另一个事件循环。

我正在使用waitForBytesWritten 方法来确保在写入所有字节之前不会重新进入我的主事件循环。这不是一种有效的方法吗？会出现哪些“细微错误”？我应该改用flush()，这会确保在写入所有待处理字节之前不会再次输入我的事件循环吗？

我am在我的应用程序中看到一些与其串行端口通信相关的奇怪行为，但我不确定是哪个“层”通信导致了问题，所以它甚至可能不是与我对QSerialPort 的使用有关。目前，我对它的起源的唯一提示是 QSerialPort 在我看到不良行为开始前不久发出 ResourceError 。这个ResourceError 会不会和我使用waitForBytesWritten 有关？

我在 Debian 7 系统上使用 Qt 5.5.1。

Answer 1

在 Unix 上，读取通知将 EAGAIN、EIO 和 EBADF 映射到 ResourceError 并停止处理进一步的读取通知，直到您调用 waitFor 函数或直到您重新打开端口。这使得QSerialPort 在您重新打开或waitFor 之前无法读取。也许将EIO 和EBADF 映射到相同的错误是有意义的。但是，由于EAGAIN 是良性的，这样处理它看起来像是一个 Qt 错误。

要查看是否是问题所在，您可以清除错误并重新调用 waitForReadyRead(0) 或 waitForBytesWritten(0) 并查看错误是否再次出现：

bool retryWaitForBytesWritten(int n, int retries = 10) {
  if (!dev.bytesToWrite()) return false;
  while (retries-- && !dev.waitForBytesWritten(n)) {
    if (dev.error() != QSerialPort::ResourceError)
      return false;
    dev.clearError(); // retry if it was a resource error
  }
  return true;
}

您主要不应该使用waitForBytesWritten，因为：

1. 它并没有像你想象的那样做。它所确保的只是QSerialPort 中的内部写入缓冲区已通过使用write 系统调用将数据提供给操作系统而被清空。这并不意味着数据已经物理发送。

2. 它可能会阻塞。不保证会屏蔽。

3. 通常不需要通知写入何时完成。如果您有一个半双工（本质上）命令-响应协议，您不在乎何时完成发送，而是何时响应已到达或超时。

   如果您有一个发送轮询命令的流协议，并且不希望生成它们的速度超过设备可以使用它们的速度，那么您应该发出命令（并在数据结构中将它们标记为“已发出”），直到bytesToWrite 已超过高水位线。然后暂停添加新命令，直到收到bytesWritten 信号通知发送缓冲区处于低水位。 readyRead 槽匹配对发出命令的响应并适当地指示它们。

因此，理想情况下，您的代码应该包含零个 waitXxx 调用。我们周围的世界是异步的。你不等待事情，你对它们做出反应。在发生某些事情之前不要停止事件循环 - 那是倒退。在你等待的那件事之前可能会发生其他事情，直到那时你才忽略它们。即使您将 I/O 推送到单独的线程，您仍然会浪费整个线程只是阻塞。在顺序伪同步代码中处理重定向控制流的事件也很困难 - 一切最终都充满了（必要的！）错误检查。有时人们会为此使用异常，这可能没问题，但在大型代码库中很难正确执行，并且任何时候您希望将控制重定向到不在调用堆栈上的代码。当您将代码明确表示为分层状态机时，在面对异步事件（例如传入数据或错误）时，更容易推断代码的正确性。

设计您的系统，使其根据异步发生的事件进行处理。如果您的 UI 的某些方面必须指示正在发送的数据的状态，那就这样吧：不要等待，不要阻塞线程。

This answer 演示了如何使用状态机框架为基于QIODevice 的设备实现异步 I/O。设置好状态后，将它们与 UI 行为联系起来是一件相对容易的事情。请参阅以下答案：one、two、three、four、five、six、seven、eight。

另外，我错了，我修正了另一个答案。 QSerialPort 不会重新进入事件循环，网络模块中的套接字也不会。