TCP sockets are outside the (current) scope of POSIX.1, and so,
wrt POSIX, their behavior is not defined. While an implementation
can be considered compliant by choosing either of the two options
offered, but, IMHO, sockets really should be handled the same as
pipes and FIFOs in this regard.
>Now, is a TCP socket defined as a "pipe of FIFO" in this case? My socket
>IS returning -1, with errno set to EINTR having read 1 byte into my
>buffer, and having "consumed" that byte from the stream.
IMO, this is a bug, even though, technically, it is not incompatible
with the POSIX specification of read().
Also, we have from the "Rationale" section (B.6.4):
POSIX.1 permits read() and write() to return the number of bytes
successfully transferred when interrupted by an error. This is
not simply required because it was not done by Version 7,
System III, or System V, and because some hardware may not be
capable of returning information about partial transfers if
a device operation is interrupted. Unfortunately, this does
make writing a Conforming POSIX.1 Application more difficult
in circumstances where this could occur.
Since Linux is not trying to be a "blind clone" of those older AT&T
Unix versions, and the transfer is from the kernel's TCP stack
(and not just some balky device driver), there is no good reason
for not doing the right thing.
--Ken Pizzini
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/