multidirectbufferIO and multibufferIO

multidirectbufferIO and multibufferIO

[Casey Marshall]

These two tests, in gnu.testlet.java.nio.channels.FileChannel, look a
bit bogus to me. They test if FileChannel artificially limits the number
of buffers processed in scattering/gathering read/write to 16, which is
definitely the case if the underlying implementation uses readv and
writev, but this limit isn't required otherwise (at least, there is no
mention of any limit in the JDK docs).

I don't see that much point in using readv/writev for file I/O, anyway,
especially because there do seem to be bugs in our implementation of it.
And at any rate, there's no guarantee that on some other system there
would be any limit like this, or if there is, that it would be the same
as it is on POSIXy systems.

Re: multidirectbufferIO and multibufferIO

[Tom Tromey]

>>>>> "Casey" == Casey Marshall <csm@gnu.org> writes:

Casey> I don't see that much point in using readv/writev for file I/O, anyway,
Casey> especially because there do seem to be bugs in our implementation of it.

Can you ask the guy who wrote this code in Classpath about his
motivations?  I don't remember them, and it would be good to know what
drove the implementation before we look at removing it.

Tom

Re: multidirectbufferIO and multibufferIO

[Casey Marshall]

Tom Tromey wrote:
>>>>>> "Casey" == Casey Marshall <csm@gnu.org> writes:
> 
> Casey> I don't see that much point in using readv/writev for file I/O, anyway,
> Casey> especially because there do seem to be bugs in our implementation of it.
> 
> Can you ask the guy who wrote this code in Classpath about his
> motivations?  I don't remember them, and it would be good to know what
> drove the implementation before we look at removing it.
> 

It's probably moot, now. I've figured out why writeGathering wasn't
working, and am working on a similar fix for readScattering. Since there
don't seem to be any problems with using readv/writev (correctly) for
files, we can leave this in.