Matthias Drochner M.Drochner@fz-juelich.de writes:
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...
Sure. I find it very unfortunate that the tty flags and the non-block flags aren't orthogonal.
- If O_NONBLOCK, we can't sleep.
Obviously, with O_NONBLOCK, read should not sleep. That's the point of O_NONBLOCK.
- 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,
Sure about that? I believe the timer should be started as soon as a character arrives to the tty driver, regardless of what system calls are made. That's also the way I read the spec you point to:
"In this case TIME serves as an inter-byte timer and is activated after the first byte is received. Since it is an inter-byte timer, it is reset after a byte is received."
In this context, I think "received" must mean that bytes arrive to the tty driver (via a the serial line or whatever).
- also, the result of poll()/select() must not depend on setting of O_NONBLOCK (stated in some standard, maybe I'll find it...)
Makes sense, too bad posix seems to not require this to be true for tty:s.
- What does "readable" mean? "will return immediately with data" or "will not block indefinitely"?
To me, "readable" mean that a plain vanilla ordinary blocking read on the fd would return immediately, with success (i.e. with data or an EOF indication) without putting my process to sleep. If a blocking read wouldn't return immediately due to the VTIME value, then the fd is *not* readable.
- 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...
Don't understand the relevance of this.
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().
And it doesn't matter if you increasing VTIME, I guess?
Hmm - this is one of the gray areas... if there is a O_NONBLOCK, should the VTIME have an effect at all?
Well, that's what you keep saying. I think the Solaris behaviour here makes perfect sense. The VMIN/VTIME are orthogonal to O_NONBLOCK, you can use one or the other, or both, and in all cases get sane behaviour. Linux and netbsd are appearantly broken (although still posix compliant on this issue), the question for lsh is how to best work around it.
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".
Thanks. This section says:
The ISO POSIX-1 standard does not specify whether the setting of O_NONBLOCK takes precedence over MIN or TIME settings. Therefore, if O_NONBLOCK is set, read() may return immediately, regardless of the setting of MIN or TIME. Also, if no data is available, read() may either return 0, or return -1 with errno set to [EAGAIN].
The second sentence says that the kernel can return immedately, without violating POSIX. The third says that the kernel can return immedately, *with 0 as a return value*.
*BLECH*
That basically means that an operating system can be perfectly posix compliant, without implementing a useful O_NONBLOCK at all (instead, O_NONBLOCK can be an alias for the older, totally braindead, O_NDELAY flag).
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...
Well, poll works on both linux and Solaris, but the way they set the various poll flags is very different. Don't know any details bsd's poll.
(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.)
That's worse, then just ignoring the error is not an option.
Exactly which version of netbsd are you using?
Regards, /Niels
PS. I think the O_NONBLOCK flag is a really bad design. I really wish kernel hackers would consider adding non-blocking syscalls like nonblock_read and nonblock_write, as suggested by djb at http://cr.yp.to/unix/nonblock.html).