readv(), writev()

[Rick Genter]

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
rge...@labs-b.bbn.COM (Internet new) Cambridge, MA 02238
rge...@bbn-labs-b.ARPA (Internet old) linus!rgenter%BBN-LABS-B.ARPA (UUCP)

[Mike Muuss]

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

[System Mangler]

In article <42...@brl-smoke.ARPA>, mi...@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 sp...@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck

[System Mangler]

In article <10...@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.