[Rxtx] read() not blocking?

[Trent Jarvi]

On Wed, 27 Sep 2006, Knute Johnson wrote:

>> Hi Knute
>>
>> This does appear to be a bug in the windows version.  I did confirm th$
>> the timeout is not behaving as expected on w32.  The Linux binaries do not
>> display the problem.
>>
>> I guess many people do like I do in reality and implement their own
>> timeout logic in their applications.
>>
>> I tried both int n = read() and read(byte[]).  They both are returning
>> right away which was not expected.  The read() is obviously more of a
>> problem returning 255/-1.  There must be a mistake in the src/termios.c
>> code.
>>
>> You might be able to get around the problem with your own code using the
>> byte[] version of read with your own timeout logic.  You could also read
>> only when bytes are available (event).  You can also check on the number
>> of bytes available before the read.
>>
>> We will have to fix this bug for the next version of rxtx but thats not
>> going to help with whats already there.  If you spot the fix before me,
>> please send it to the list.  Otherwise I'll try to get to it as time
>> allows on the weekends.
>>
>
> I've got a lot of running software in the wild that I was trying to
> convert to RXTX because of the unavailability of Sun's
> implementation.  Unfortunately I really need the blocking
> capabilities as there is a lot of code to rewrite otherwise.  I guess
> for now I'll just have to use Sun's code.
>
> I haven't done any UART programming in a lot of years but if you
> point me to the code I would be happy to take a look at it.
>
> Thanks,
>
>

Hi Knute

I wish I had time to just jump in and find this bug.  I'm sure I'll get to 
it but probably not as fast as you would like.

The COMMTIMEOUTS structure in termios.c is what controls the 
kernel driver on top of the UART.  The windows API calls are 
SetCommTimeouts and GetCommTimeouts.

I suspect the bug is here:

         if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 )
         {
                 /* read blocks forever on VMIN chars */
         } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 )
         {
                 /* read returns immediately */
                 timeouts.ReadIntervalTimeout = MAXDWORD;
                 timeouts.ReadTotalTimeoutConstant = 0;
                 timeouts.ReadTotalTimeoutMultiplier = 0;
         }

I do not know what the bug is without further investigation.  There is 
also the possibility that reads are not making the right assumptions in 
termios.c (serial_read()).

As Linux is working, the bug is in the termios.c file.  The code is going 
through the same path in SerialImp.c for w32 and linux.  So once read is 
behaving like a Unix/Linux read, the rest will fall into place.


--
Trent Jarvi
tjarvi at qbang.org