mixing O_NONBLOCK and raw tty causes portability problems

[Matthias Drochner]

nisse@lysator.liu.se said:
> I rely on the following behaviour of VMIN > 0 and VTIME > 0, as
> described by the glibc manual: 
> [...]
>      `read' always blocks until the first character arrives

This obviously refers to the !O_NONBLOCK case...

> if I call read after that
> poll/select have said that a fd is readable, then read on that fd
> shouldn't return EWOULDBLOCK.

Well the VMIN and VTIME stress the notion of "readable" somehow.
One can take various approaches, or have different precedences:
- If O_NONBLOCK, we can't sleep. Not even for the VTIME timeout?
  VTIME can be macroscopic, so we shouldn't probably. If so, VTIME
  is pointless.
- A tty file descriptor might not be considered "readable" unless it
  fulfills the VMIN/VTIME conditions. Now there are some pitfalls:
  - a VTIME timeout begins at the time the read() call is done, so
    any poll() (or select(), ftm) isn't supposed to care about timing
  - also, the result of poll()/select() must not depend on setting
    of O_NONBLOCK (stated in some standard, maybe I'll find it...)
  - What does "readable" mean? "will return immediately with data"
    or "will not block indefinitely"?
- One could assume: If a read() returns with less than VMIN chars,
  there was a gap of at least VTIME after the last. This might hold
  in presence of O_NONBLOCK or not...

For me, it seems pointless to make a sense of these contradicting
requirements, the only thing which helps is to avoid certain
situations.
In particular, VTIME and O_NONBLOCK can't coexist, neither can
VMIN and poll()/select().

> On netbsd, if you type quickly, will read return several characters at
> a time?

I can't type quick enough to get more characters between the poll()
and the read(). If I replace the poll() by a sleep(), the read()
indeed returns as many characters.

> I also tried your test program on SunOS 5.9
> [...]
> then I increased VTIME to 10 to get a more
> noticable effect

Hmm - this is one of the gray areas... if there is a O_NONBLOCK,
should the VTIME have an effect at all?

> > Indeed, in SUSv2's termios page is a sentence which says that if
> > both O_NONBLOCK and VTIME>0 are set, the behaviour is more or less
> > undefined.
> Hmm, can you point me to the right place to read that?

http://www.opengroup.org/onlinepubs/007908799/xbd/termios.html
The sentence I was referring to is in the "Non-canonical Mode Input
Processing" chapter, beginning
"The ISO POSIX-1 standard does not specify".

> Does it matter if one uses poll or select? If so, that may be a reason
> to prefer one over the other.

I believe this is just a matter of the user interface. Both very likely
base on the same kernel function. So they will behave identically.

> (In general, I think the poll interface
> is nice and clean, but in practice the details differ so much between
> different systems that it is painful to use in portable code. select
> behaviour is much more uniform).

select() is older and supported on more systems, agreed. Nowadays I'd
assume that poll() works on every system I'd consider worth working
with...

> What happens if one jsut ignores the
> EWOULDBLOCK error?

I didn't try yet, but I'd assume that no tty input is accepted unless 4
characters are typed in.
(My failure report wasn't very precise, sorry. Actually, I didn't get
just a single "EWOULDBLOCK" message after a keystroke, but lsh went into
an endless loop printing these messages after I pressed a key.)

> I don't quite like setting VMIN to 1

As said above, I _believe_ that VMIN>1 and poll()/select() together lead
to nonportable code...

best regards
Matthias