Re: [RFC] adding aio_readv/writev

[Clement T. Cole]

>>Comments, reasons for not doing async readv/writev directly welcome.

How about the case for it...  See Pages 404-406 [Section 12.7] of
Richard Steven's ``Advanced Programming in the Unix Environment''
[aka APUE].  Richard measures almost a factor of 2 difference
in system time between using vectored I/O and not using it on
a Sun and on a x86.

>>- there exists at least one major application class (databases)
>>  that uses vectored I/O heavily and benefits from async I/O.
>>  Hence async vectored I/O is also likely to be useful. Can anyone
>>  else with experience on other OS's comment on this ?

			....  a number of other comments/arguments from other
			....  responces removed to get the meat of the discussion.

Becareful out there.....

Large commercial applications such as Oracle DB, IBM's DB2 or
Netscape Enterprise server for that matter - are very modular in
their interface to OS because they have to be and have been, ported
and tuned to run on a number of different OS's and HW architectures.
When I see some one say something about ``Oracle'' doing X or Y -
I get a little worried.

Which version, which port etc...  e.g. Oracle's DB running on VMS
has a different I/O system interface that is different from any of
it's Unix implementations...... oh yes - was the clustered or
not... did it have the X package etc...

The point is that the UNIX implementations of Oracle DB vary
widely.....  This is also true of every >>major<< application package
I have worked/consulted seen some of the insides (SAP, Informix,
Netscape,  etc...).

Solaris and Tru64 [and I would expect AIX, HP-UX
etc... but I only know these two personally] each offer
a highly parallel I/O, asynchronous (but proprietary) interface.
Oracle's Sun group (or the old DEC group) exploit the >>private<<
interfaces -- to make the code work better - they do.

That may or may not be what you have seen on some ``simple Un*x''
port - which is a starting point for them - that's not the code
they ship on the high end revenue systems.

Oracle/IBM/Netscape etc... do this cause the want to grab customers
from their competetors (DB2, Informix, etc.)... they invest in
using the best interfaces available.... if they are available
AND if they can help them sell more copies of their product.

So... let's get back to the basic issue....

We know that vectored/scatter gather I/O can help a number of real
applications ... Richard demonstrated that.  We have some examples
[like DB2] that have use vectored I/O successfully.  We also
know asynchronous I/O has been demonstrated to be useful and
know that some commerical folks have used that.  

I'm gather from some of the comments, adding async/vectored
will make an already complex subsystem, even more so [i.e. not
a resounding endorsement for sure this is easy].

So the question is can async vectored I/O be implemented 
to have a positive gain, such as it did within the traditonal one.
If the complexity is too high and it does not help much...then
maybe this is a Chimera to leave alone.   But.... if it can be
done with some level of elegance... well.... the past history is
that the commerical folks have used those features.

I know this this sounds a little bit like:
	``if you build it - they will come.'' 

But I would say it's more to this point:
	 ``if you build it and this new feature shows some real value
	   AND the application can exploit it ...  in time, they will
	   because if they don't their competetors will.''

Clem Cole