Re: readv/writev

["Conrad Scott" <Conrad dot Scott at dsl dot pipex dot com>]

Robert Collins wrote:
>
> Yes but: you are only testing half of the changes.
> How much slower/faster has readv /writev gotten?
> So I'm suggesting a 'race' between read and readv
> on /dev/zero. If readv has gotten at least 0.5us
> faster (say) then overall it should be good.

There's no comparison possible right now since the existing code
for writev/readv calls read/write once per iovec structure, while
(for iovcnt > 1) my mod. alloca's a buffer and calls read/write
once w/ the buffer copied as appropriate.  This is necessary at
least for sockets since the result of a readv/writev is meant to
be atomic.  In fact, it needs to be this way even for file IO,
since otherwise several simultaneous writev's in append mode could
end up interleaving their output, which is not how it should be.
It's a bit of a pain w/ large IO buffers of course.  (The code is
optimized to avoid the alloca/memcpy if there's only one iovec
structure; so the usual read/write case drops through w/o any
copying).

I've looked at putting in readv/writev directly for disk files
etc. (pipes and raw devices would benefit as well) but a general
solution doesn't fit very well w/ the current structure of the
fhandler classes: for example, the text-mode vs binary-mode code
and something else I can't quite remember just now :-)

> Uh, overlapped maps nicely onto select/poll
> -for the most part-. It's ZeroCopy that is the real
> challenge. And one (not the only) POSIX api that does
> this is aio_write and aio_read.

I'd have thought that overlapped was the reverse of the Posix
select/poll model.  That is, in NT you issue your IO operation and
got told when it has completed, which allows for zero-copy IO and
for queues of operations (shades of VMS indeed); while the
select/poll model is the opposite: you get told when a read/write
would succeed if you were to do it.  You can't, w/ select/poll,
issue a nonblocking IO operation and be told when it has completed
(except for the strange cases of accept and connect).  And it's
not clear to me how to bridge that gap.

As you mention tho', the aio i/faces support exactly this model,
which I'd forgotten about completely.  These would be a good bet
to implement someday.

> You may find this
> <http://www.kegel.com/c10k.html> an interesting read.

Thanks for the reference: it's looking very good so far.  Thanks
also for the offers of code: I'll pass for the moment, since I
think I'll get back to doing the cygserver code for the moment and
leave this marvellous field wide-open for some other brave soul.

Cheers,

// Conrad