Why doesn't NIO provide an async-singlethreaded I/O?

[Brunoais]

Hey Alan.

I ended up using AsynchronousFileChannel to do the reading work for the 
implementation of the class. I've submitted it for peer reviewing but I 
don't know if anything is being done about it.

After reading the C code, it seems like there's no real advantage 
between FileChannel::map and AsynchronousFileChannel for reads although 
there are hints that there can exist some advantages with 
AsynchronousFileChannel if there's a lot of processing between reads.

If you can, I'd like you to review the speed tests I made to see if I 
missed or entered in a pitfall anything in the process

Finally, I'll just reinstate that, in my local tests on a windows 10 
machine, I got ~2.8s of improvement reading a 1GB file that takes 
~20-23s to read. I don't have any tests for when the OS is concurrently 
scheduling reads but I think it is an great improvement for situations 
when a server is the only thing reading and writing to/from disk where 
the seconds stack up as the operations also stack on each other.

On 28/10/2016 11:00, Brunoais wrote:
> Thank you!
>
> That helped me deciding a possible direction to go to. I'll checkout 
> that FileChannel::map method as well as Asynchonous.
>
> I still do not know about why there's no non-blocking I/O in java but 
> that's fin, I guess.
>
> I'll see what I can do with this information.
>
>
> On 28/10/2016 09:46, Alan Bateman wrote:
>> On 28/10/2016 08:54, Brunoais wrote:
>>
>>> Please read the quotes.
>>>
>>> They are from the thread "Re: Request/discussion: BufferedReader 
>>> reading using async API while providing sync API" from the mailing 
>>> list core-libs-dev at openjdk.java.net .
>>>
>>> The main question I have can be summarized to:
>>>
>>> Why isn't there (or was there) any non-block read-ahead I/O in 
>>> java's NIO (more question information in the quotes)?
>> If you looking to read ahead then a thread + synchronous I/O should 
>> work just fine, you don't need any additions to the Java SE APIs to 
>> do that. As always, do your performance tests to see if helps or not. 
>> I see Peter has provided some JMH examples, include dropping the file 
>> system cache between runs.
>>
>> One other thing to add to your list to try is memory mapping the file 
>> with FileChannel::map and MappedByteBuffer. In particular, see if 
>> MappedByteBuffer::load helps.
>>
>> (Aside from MappedByteBuffer::load, none of the existing APIs map to 
>> fadvise or madvise, in particular there is no way to advise that the 
>> access is expected to be sequential)
>>
>> As regards AsynchronousFileChannel (which is the only non-blocking 
>> file I/O API in the platform) then it's not for sequential access. 
>> You can make it do sequential access of course but it will be a bit 
>> of work to do right.
>>
>> -Alan
>>
>