Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!luth!sunic!dkuug!freja!skinfaxe!thorinn
From: thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.unix.wizards
Subject: Re: why limit of 16 iovec's in readv/writev?
Keywords: iovec readv writev
Message-ID: <5005@freja.diku.dk>
Date: 26 Nov 89 14:56:45 GMT
References: <473@siswat.UUCP> <4996@freja.diku.dk> <478@siswat.UUCP>
Sender: news@freja.diku.dk
Lines: 24

buck@siswat.UUCP (A. Lester Buck) writes:
>In article <4996@freja.diku.dk>, thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen) writes:
>> In my opinion you should not use the readv/writev mechanism to provide
>> packet delimiters.

>Reasons, please?  Works just fine for me.
>Why not use readv/writev if they are there?

Normally, the 4.3 BSD kernel does its best to treat all the iovecs in
a single call to readv/writev as one continuous buffer --- that
includes the PF_REMOTE mode of pseudo-ttys, for instance. That's why I
thought that it would be confusing to use other semantics, and that it
should therefore be avoided.

But it turns out that I had overlooked the "physical I/O" character
devices, such as raw tapes (and disks, and so on). These devices call
the physio routine, which in turn calls the driver's strategy routine
once (at least) _per_iovec_. On tapes this gives one tape block per
iovec (I think). So, after all, your usage is actually quite
consistent with the system. Sorry for the confusion.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcvax!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk