That is probably because *usually* all of the data is accepted by
one write[v]. But the specification is quite specific in stating
that a short write is not an error.
> I
> would believe a lot software would break if write returned partial
> results on blocking software.
That is bad programming then. If you look in a text such as "UNIX
Network Programming" by Richard Stevens, or the manual page for write
under Solaris, or even (gasp) the documentation for send() on Windows NT,
they all speak of partial writes on a socket.
The "standard" way to handle a write on a socket correctly is:
p = buffer;
while (len > 0) {
if ((n = write(s, p, len)) < 0) {
/* bad something has happened */
}
p += n;
len -= n;
}
> On the reading side the bahaviour is
> known and the applications compensate for that. The description at
> <http://www.opengroup.org/onlinepubs/007908799/xns/send.html> makes me
> believe that write/send shouldn't do partial things on blocking sockets.
Without checking the URL (I only have e-mail access here), your link
mentions XNS, this is not TCP/IP, and its semantics may be different. In the
case of a sequenced packet protocol like SPP which is the common transport
layer on XNS, having partial writes on a socket has a rather serious
meaning. It is breaking the message boundaries and therefore it probably
does not make sense to have partial writes, you want it to all go at once.
However XNS is obsolete AFAIK.
> - --
> Jens-Uwe Mager <pgp-mailto:62CFDB25>
>
> Please read the FAQ at http://www.tux.org/lkml/
Jonathan
-
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/