是否必须在RXTX中进行常规轮询? [英] Is constant polling in RXTX necessary?

查看:304
本文介绍了是否必须在RXTX中进行常规轮询?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在尝试找出此问题时(感谢任何帮助),我跑了RXTX使用 PortMon 监控其活动,并注意到RXTX会不断检查是否即使Java客户端仅通过SerialPortEventListener从gnu.io.SerialPort对象读取数据,也可以使用数据。

While trying to figure out this problem (any help there is appreciated), I ran RXTX while monitoring its activity using PortMon and noticed that RXTX constantly checks if data is available, even when the Java client reads from the gnu.io.SerialPort object only through a SerialPortEventListener.

这是为什么?这是RXTX人员糟糕的实现选择,Sun的API选择不好(因为RXTX遵循javax.comm API),或者本机代码支持运行Java的限制?

Why is this? Is it a poor implementation choice by the RXTX folks, a poor API choice by Sun (since RXTX follows the javax.comm API), or a limitation of running Java supported by native code?

另一方面,超级终端不进行轮询(并且没有问题)。是否可以访问一些隐藏的Windows系统调用来执行此操作?

Hyperterminal, on the other hand, does no polling (and works without a problem). Does it have access to some hidden Windows system calls that let it do this?

推荐答案

不,这不是由于javax.xomm API。 Rxtx可以通过该API使用,也可以不使用。

No it's not due to the javax.xomm API. Rxtx can be used through that API or not by the way.

Rxtx内部有点不同/怪异但有一些错误。
短版本,这是它应该如何工作:你有两个参数:超时和阈值。根据源代码将超时设置为0(无)并将阈值设置为1(返回前至少需要1个字节)应该通过InputStream定义阻塞读取给我们正常。

Rxtx internals are a bit different/weird though and has some bugs. Short version, this is how it is supposed to work: You have two parameters to play with: timeout and threshold. According to the source code setting the timeout to 0 (none) and threshold to 1 (requiring at least 1 byte before returning) should give us normal, by InputStream defined, blocking reads.

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

The problem is that even when setting it up like this there is a bug in the current stable release (2.1.7r2). The threshold parameter is always set to 0! From the source code:

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

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

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

The confusing part is that this was also the case in 2004 and reported on the mailing list and fixed, but it was either not really fixed or has come back again (a regression). There is actually a new bug report that for some reason I couldn’t find at first. I eventually found it going throw the pre-release package source code and found an otherwise not published change log (the web page doesn’t show change logs after the last stable version, its available in CVS though).

解决方案


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

  2. 制定一个丑陋的解决方法:

  1. It is fixed on HEAD, so you can use the latest pre-release version (2.2-series) or compile it from CVS.
  2. Make an ugly workaround along the lines of:

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


然后你这样做: 读取(in)而不是 in.read()

Then you do: read(in) instead of in.read().

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

I actually wrote a blog entry about this 2 years ago so I wouldn't forget.

这篇关于是否必须在RXTX中进行常规轮询?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆