rgenter@LABS-B.BBN.COM (Rick Genter) (09/29/86)
Can someone explain why readv()/writev() are system calls? As far as I can tell the only advantage to having them be syscalls is to prevent the user from having to either a) issue multiple read() calls or b) allocate twice as much buffer space and use bcopy(). Is there another reason? -------- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/512 rgenter@labs-b.bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbn-labs-b.ARPA (Internet old) linus!rgenter%BBN-LABS-B.ARPA (UUCP)
mike@BRL.ARPA (Mike Muuss) (09/30/86)
Exactly right. readv() and writev() allow one to, say, transmit a packet (header+data) from two separate buffers as one unit, without needing either (a) extra system calls, or (b) a bcopy(). Small efficiency nit, you say. True, EXCEPT for the fact that the 4.2 TCP sets the TCP_PUSH bit at the end of each sys-write. This can have extreme effects on network performance. Note that readv() and writev() have a maximum vector length of 16 items in 4.2 BSD. You will find this limit strictly enforced by the kernel, and perplexing to the unwary. -Mike
mangler@cit-vax.Caltech.Edu (System Mangler) (10/11/86)
In article <4251@brl-smoke.ARPA>, mike@BRL.ARPA (Mike Muuss) writes: > Exactly right. readv() and writev() allow one to, say, transmit > a packet (header+data) from two separate buffers as one unit, > without needing either (a) extra system calls, or (b) a bcopy(). bcopy() is about 4 times as fast as pipes for copying data. On raw devices, physio() generates a physical I/O for each element of a readv() or writev(). The far more common read() and write() are implemented in terms of the more complicated readv() and writev(), slowing down the former two system calls. I doubt that the gains of readv() and writev() are used frequently enough to win back the speed loss to read() and write(). Really now, how often do you call perror()? Don Speck speck@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
mangler@cit-vax.Caltech.Edu (System Mangler) (10/12/86)
In article <1035@cit-vax.Caltech.Edu>, I write: > On raw devices, physio() generates a physical I/O for each element > of a readv() or writev(). I was wrong; only one I/O is generated, because readv() and writev() on the raw device won't do more than a single iovec, due to bugs in physio(). 4.3bsd fixes one of the bugs, but there's still at least one bug left: writev() fails on the second iovec, with errno=ENXIO. If readv() and writev() were useful, someone would have fixed this. Don Speck speck@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
loverso@sunybcs.UUCP (John Robert LoVerso) (10/14/86)
In article <1035@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: > I doubt that the gains of readv() and writev() > are used frequently enough to win back the speed loss to read() > and write(). Really now, how often do you call perror()? And how often to you call psignal()? As of 4.3 beta, it still used 4 separate write()s rather than a single writev() as in perror()...