java - RXTX 中是否需要不断轮询？

Question

在试图找出 this problem 时(感谢任何帮助)，我在运行 RXTX 的同时使用 PortMon 监控其 Activity 并注意到 RXTX 不断检查数据是否可用，即使 Java 客户端仅通过 SerialPortEventListener 从 gnu.io.SerialPort 对象读取也是如此。

这是为什么？是 RXTX 人员的错误实现选择、Sun 的错误 API 选择(因为 RXTX 遵循 javax.comm API)，还是本地代码支持运行 Java 的限制？

另一方面， super 终端不进行轮询(并且可以正常工作)。它是否有权访问一些隐藏的 Windows 系统调用以执行此操作？

Answer 1

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

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

问题是，即使像这样设置，当前稳定版本 (2.1.7r2) 中也存在错误。阈值参数始终设置为 0!来自源代码:

/* 测试 ttyset.c_cc[VMIN] = 阈值； */ttyset.c_cc[VMIN] = 0;

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

解决方案

1. 它固定在 HEAD 上，因此您可以使用最新的预发布版本(2.2 系列)或从 CVS 编译它。

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

   int read(InputStream in) throws IOException {
     int b; 
     while ((b=in.read()) == -1) { 
       try { Thread.sleep(10); } catch (InterruptedException e) { }
     }
     return b;
   }
   

然后你做:read(in) 而不是 in.read()。

我实际上写了a blog entry about this 2 年前所以我不会忘记。