Hi Åke,

On Mar 11 21:48, Åke Rehnman via Cygwin wrote:
> Hello all,
> 
> opening a file (serial port) with O_NONBLOCK and subsequently setting
> termios VMIN and VTIME > 0 makes read() never ever return any data (returns
> EAGAIN indefinitely).
> 
> Don't ask my why one would want to do something like this but apparently the
> "screen" program think this is a good way of doing things...
> 
> Nevertheless not returning any data ever seems wrong.
> 
> Any insight on how it is supposed to work is welcome.

[Please note that I can't test this myself, so we may need a bit of
 back and forth over this issue]

For a start, can you please strace the problem with a simple
testcase,like this:

  $ strace -o serio.trace <yourtestcase>

and send the source of your testcase as well as the serio.trace file
here?  It may show at which point the error code is generated.

I inspected the serial I/O read function and I only see a subtil
difference in terms of VMIN/VTIME which doesn't seem to be the culprit
at first glance.  In O_NONBLOCK mode, the underlying Windows function
ReadFile is called unconditionally.  My current hunch is this:

- If VMIN>0 && VTIME>0, the Windows equivalent of tcsetattr is
  told that VMIN>0.

- So, assuming VMIN == 2 in Windows.  If VTIME > 0, the Cygwin read
  function sets the number of bytes_to_read to 1 (this is old code,
  don't ask why).

- My assumption now is that the ReadFile function fails because it's
  supposed to return only 1 char, but VMIN is > 1.

There are two issues here.

- If my assumption is correct, the tcsetattr function must not
  set the Windows VMIN equivalent to != 0 in the O_NONBLOCK case.

- Also, as mention above, if VTIME > 0, Cygwin's read sets the number of
  bytes_to_read to 1.   Weirdly, it does so even if there are more than
  1 byte in the inbound queue.  This sounds wrong to me.

Ok, that's for a start, let's see if we can fix this behaviour.


Thanks,
Corinna
  
-- 
Corinna Vinschen
Cygwin Maintainer