RXTX 中是否需要持续轮询？

Question

在试图找出这个问题时（感谢任何帮助），我在监控时运行了 RXTX使用 PortMon 进行活动，并注意到 RXTX 不断检查数据是否可用，即使 Java 客户端仅通过 SerialPortEventListener 从 gnu.io.SerialPort 对象读取。

这是为什么呢？这是 RXTX 人员的一个糟糕的实现选择，还是 Sun 的一个糟糕的 API 选择（因为 RXTX 遵循 javax.comm API），或者是本地代码支持的运行 Java 的限制？

另一方面，超级终端不进行轮询（并且工作没有问题）。它是否可以访问一些隐藏的 Windows 系统调用来执行此操作？

Answer 1

不，这不是由于 javax.xomm API 造成的。顺便说一句，Rxtx 可以通过该 API 使用，也可以不使用。

Rxtx 内部结构有点不同/奇怪，并且有一些错误。
简短版本，这就是它应该如何工作：您有两个参数可以使用：超时和阈值。根据源代码，将超时设置为 0（无）并将阈值设置为 1（在返回之前需要至少 1 个字节）应该会为我们提供正常的（由 InputStream 定义的）阻塞读取。

问题是，即使这样设置，当前稳定版本（2.1.7r2）中也存在错误。阈值参数始终设置为 0！从源代码：

/* TESTING ttyset.c_cc[ VMIN ] = Threshold; */
ttyset.c_cc[VMIN] = 0;

令人困惑的部分是，2004 年也是这种情况，并在邮件列表上报告并修复了，但它要么没有真正修复，要么又回来了（回归）。实际上有一个新的错误报告，由于某种原因我一开始找不到。我最终发现它会抛出预发布包源代码，并发现一个未发布的更改日志（该网页在最后一个稳定版本之后不显示更改日志，尽管它在 CVS 中可用）。

解决方案

1. 已修复在HEAD上，因此可以使用最新的预发布版本
   （2.2-系列）或从 CVS 编译它。

2. 按照以下方式制定一个丑陋的解决方法：

   int read(InputStream in) 抛出 IOException {
     整数b； 
     while ((b=in.read()) == -1) { 
       尝试 { Thread.sleep(10); } catch (InterruptedException e) { }
     }
     返回b；
   }
   

然后您执行：read(in) 而不是in.read()。

实际上，我两年前写了关于此的博客文章，所以我不会忘记。