mixing O_NONBLOCK and raw tty causes portability problems
Wed, 15 Oct 2003 22:51:39 +0200
> 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
- 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
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?
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
> 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...