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