On 03/21/2014 10:17 AM, Michael Kerrisk (man-pages) wrote:
On Fri, Mar 21, 2014 at 3:03 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
On 03/21/2014 09:15 AM, Michael Kerrisk (man-pages) wrote:
On 03/21/2014 12:21 PM, Peter Hurley wrote:
On 03/21/2014 06:45 AM, Michael Kerrisk (man-pages) wrote:
Finally, if the 'count' parameter is less than MIN, read() may return
before
MIN bytes have been received, if 'count' bytes have been received.
Yes. But it's not clear to me here: do you mean that something in the
man page (or in TLPI) needs fixing?
Well, what I mean here is that read() may also _not_ return until MIN
bytes have
been received, even if 'count' bytes have been received.
Ahh -- I see what you mean. And, it looks like there is a point here where
Linux
differs from POSIX and (at least) Solaris. See the current man-page text
below,
in particular the MIN>0, TIME>0 case. I've also attached a simple test
program
that I used, below.
In noncanonical mode input is available immediately (without the
user having to type a line-delimiter character), no input pro‐
cessing is performed, and line editing is disabled. The settings
of MIN (c_cc[VMIN]) and TIME (c_cc[VTIME]) determine the circum‐
stances in which a read(2) completes; there are four distinct
cases:
MIN == 0; TIME == 0:
If data is available, read(2) returns immediately, with
the lesser of the number of bytes available, or the number
of bytes requested. If no data is available, read(2)
returns 0.
MIN > 0; TIME == 0:
read(2) blocks until MIN bytes are available, and returns
up to the number of bytes requested.
MIN == 0; TIME > 0:
TIME specifies the limit for a timer in tenths of a sec‐
ond. The timer is started when read(2) is called.
read(2) returns either when at least one byte of data is
available, or when the timer expires. If the timer
expires without any input becoming available, read(2)
returns 0. If data is already available at the time of
the call to read() the call behaves as though the data was
received immediately after the call.
MIN > 0; TIME > 0:
TIME specifies the limit for a timer in tenths of a sec‐
ond. Once an initial byte of input becomes available, the
timer is restarted after each further byte is received.
read(2) returns when any of the following conditions is
met:
* MIN bytes have been received.
* The interbyte timer expires.
* The number of bytes requested by read(2) has been
received. (POSIX does not specify this termination
condition, and on some other implementations read()
does not return in this case.)
Because the timer is started only after the initial byte
becomes available, at least one byte will be read. If
data is already available at the time of the call to
read() the call behaves as though the data was received
immediately after the call.
POSIX does not specify whether the setting of the O_NONBLOCK file
status flag takes precedence over the MIN and TIME settings. If
O_NONBLOCK is set, a read() in noncanonical mode may return imme‐
diately, regardless of the setting of MIN or TIME. Furthermore,
if no data is available, POSIX permits a read() in noncanonical
mode to return either 0, or -1 with errno set to EAGAIN.
All looks good.
Peter, do you agree that Linux appears to differ from POSIX here? (Not
sure if you tried my test program to verify...)
I did run the test program to validate that it's observed behavior is that
implemented by Linux, with which I'm very familiar.
I don't have a test setup for other *nixes.
I would be interested to know the results of
./noncanonical 0 5 3 0
hello
and
./noncanonical 0 5 3 2
hel
on other platforms.
With respect to POSIX compliance, it's hard to say. I'm not sure the
spec contemplates the degenerate case where max bytes < MIN. And specifically
with regard to terminal i/o behavior, POSIX is essentially ex post facto,
and is really documenting existing behavior.
Other than the degenerate case of max bytes < MIN, is there any other
variation between Solaris and Linux in non-canonical mode?
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
