Re: mixing O_NONBLOCK and raw tty causes portability problems
Matthias Drochner <[email protected]>
| Newsgroups | gmane.network.lsh.bugs |
|---|---|
| Message-ID | <[email protected]> |
[only a short reply, will be AFK until monday night] [email protected] said: > > - 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 > [...] > "In this case TIME serves as an inter-byte timer and is activated > after the first byte is received. Only a few lines later: If the data is in the buffer at the time of the read(), the result will be as if the data has been received immediately after the read(). > > the result of poll()/select() must not depend on setting > > of O_NONBLOCK Here is a reference: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html > If a blocking > read wouldn't return immediately due to the VTIME value, then the fd > is *not* readable. If you take that and assume that the result of select()/poll() does not depend on O_NONBLOCK, then your code with VMIN==4 can't work as expected. The callback wouldn't be called until 4 characters are received. (D'UNIX appearently behaves this way, but neither Linux nor NetBSD) The only way around this I can imagine is to have VMIN==1 most of the time; to get characters coalesced for efficiency, VMAX could be set to 4 for the time of the read() (and the O_NONBLOCK cleared). What a mess... (this would effectively mean that O_NONBLOCK is useless on the stdin tty descriptor) > poll works on both linux and Solaris, but the way they set the > various poll flags is very different. I wasn't aware of this... > Exactly which version of netbsd are you using? Newest bleeding edge current on i386. I can do tests on older releases if needed, and perhaps also on other architectures (alpha, mips, m68k). best regards Matthias