[Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close()
Kustaa.Nyholm at planmeca.com
Thu Mar 3 13:02:30 MST 2011
On 3/3/11 20:48, "Ryan Boder" <ryan.boder at gmail.com> wrote:
>On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm
><Kustaa.Nyholm at planmeca.com> wrote:
>On 3/3/11 16:56, "Ryan Boder" <ryan.boder at gmail.com> wrote:
>>I'm not assuming the entire message has arrived, I'm just assuming it
>>either has arrived or will arrive soon which is why I'm using a
>>(supposedly) blocking read().
>I've been giving this some further thought.
>It does not feel healthy to block without timeout, especially
>from within a thread that is essentially internal to the rxtx.
>I've never done that, I always use a time out, read(byte,int,int)
>for the expected number of bytes, check how much I got and issue
>more reads until I get everything.
>You have not described how your communication works so I'm only
>If your device needs some response to send more bytes (from your
>code it looks like this is not the case) then a missing byte
>would block your read and prevent you from responding and
>getting more data. But as said, looks like that is not the case.
>Anyway, if this was my problem, I would enable the timeout
>and use read(byte,int,int) and loop until I get what I need.
>You are right, I should and will use a timeout. In fact, my program has
>been running flawlessly for 12 hours and the only change I made was to
>enable a timeout, no change in the logic at all. Without the timeout
>read() was returning -1 usually after it ran for an hour or two. I will
>change the code to make use of the timeout and handle it appropriately.
>It still seems to me that RXTX's behavior doesn't match the documentation
>when rx timeout and rx threshold are disabled read() should block until
>data is available instead of immediately returning -1.
Yeah, it does look like bug. However this might be related to some
Windows specific serial port issue. Years ago I had issues with
JavaComm (not RxTx) where I did a blocking read and I had huge
issues with my program consuming all resources. I curser the Sun
and JavaComm and re-code my own SerialPort using JNI to access
the Win32 API directly. And I run into the same problems as
with the Sun's implementation! So I ditched my code, changed
my code to use timeouts and problems disappeared.
> I don't believe that a framing error is occurring immediately every time
>data is not available causing read() to return -1. Especially since the
>C# test program above runs all day with no error and the Java program
>above runs all day with no error when a timeout is enabled.
I think so too, all things considered I don't really believe in framing
in this case.
> To me it seems like enabling the timeout is what is causing read() to
>block until data is available, even if only for 1600ms, and without the
>timeout read() is returning -1 immediately when it should be blocking.
Yeah, I had a peek at the innards of RxTx Windows serial port a week
or so ago and also read MSDN documentation about serial ports and
the way overlapped and non-overlapped (non blocking and blocking)
IO is handled is a way different. So yeah, it can well be that
there is an issue lurking there somewhere inside RxTx in Windows.
>Thanks for all the help and best regards,
I'm happy if I was of any assistance.
More information about the Rxtx