Messages in this thread | | | Date | 03 Jun 1999 10:13:03 +0200 | From | Jonathan NAYLOR <> | Subject | Re: writev() BUGS! |
| |
> >It is not getting fixed, because there is nothing to fix. > > Uhm, are you sure? I have never seen that behaviour on any > other Unix. If a socket is in blocking mode, writev (or send) > is supposed to sleep until all is send or an error occurs.
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/
| |