Is continuous polling required in RXTX?

Question

While trying to find out this problem (any help would be appreciated), I started RXTX, watching 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 SerialPortEventListener .

Why is this? Is this a bad choice for people to implement RXTX, a bad choice for the Sun API (since RXTX follows the javax.comm API) or a restriction on the use of Java supported by native code?

Hyperterminal, on the other hand, does not poll (and works without problems). Does he have access to some hidden Windows system calls that allow this?

Answer 1

No, this is not related to the javax.xomm API. Rxtx can be used through this API or not.

The internal elements of Rxtx are slightly different / weird, although they do have some bugs. A short option, here is how it should work: you have two parameters for the game: timeout and threshold. In accordance with the installation of the source code, the timeout to 0 (no) and the threshold value to 1 (at least 1 byte is required before returning) should give us a normal, using InputStream, blocking reading.

The problem is that even with this type of configuration, an error occurs in the current stable version (2.1.7r2). The threshold parameter is always set to 0! From the source code:

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

The confusing part is that it was the same in 2004, and was reported on the mailing list and fixed, but it either was not fixed or returned again (regression). Actually there is a new bug report which for some reason I could not find at the beginning. In the end, I found that it runs the source code of the package before release, and I discovered an otherwise unpublished change log (the web page does not show change logs since the last stable version, although it is available in CVS).

Decision

• It is fixed on HEAD, so you can use the latest version before release (2.2-series) or compile it from CVS.

• Make an ugly workaround line by line:

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

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

I actually wrote a blog entry about this 2 years ago, so I have not forgotten.