AIO and some advice needed.

[Avinash Lakshman]

The close() thing may have been a false alarm. But we are keeping a close
eye on it. Will keep you posted.
As far as your earlier comment:

* If I were to use the latter how would one handle reads like the ones that
occur in our application:

(1) seek(position);
(2) readUTF() - read a key value.
(3) readInt() - size of the data associated with the data.
(4) .....

We need to perform little reads before we know what the result is.
This may not be a good candidate. Is this a sequential file or do you know
the file position of data you will need in the future? (in order words, does
the file position for a read depend on the previous read?)*

Yes I know the position. So in order to avoid convoluted programming what we
are trying to do is submit the read request and suspend the continuation.
When the completion handler is done we release the continuation to continue
with where we left off. Does this sound reasonable? It almost as if sounds
like unless the entire system is asynchronous there is not much to gain from
AIO. Is my conclusion correct?

Avinash

On Wed, Nov 26, 2008 at 9:16 AM, Alan Bateman <Alan.Bateman at sun.com> wrote:

> Avinash Lakshman wrote:
>
>> Hi All
>>
>> I have been evaluating AIO and along the way I learnt that it goes a long
>> to help out the NCQ features that are available in today's SATA drives
>>
> The main thing is to have drivers that support it. I don't know what
> operating systems you use but Solaris 10 and Linux have come with AHCI
> drivers for some time. I think you need may special drivers for older
> versions of Windows.
>
>
>>
>> (1) Submit the read/write request and then wait on the returned future
>> pointer - which looks like a synchronous read/write to me. It appears one
>> cannot take advantage of NCQ over here.
>>
> You could initiate several I/O requests and then iterate over the Futures
> to wait on all the results. The only complication is that you would need to
> deal with short reads (meaning the read completed with less bytes that you
> expected).
>
>  (2) Submit the read/write request and then handle the result in the
>> completion handler as opposed to blocking on a future pointer. This really
>> takes advantage of the NCQ features since the thread is not blocked and more
>> requests can be submitted to take advantage of the NCQ features.
>>
>> If I were to use the latter how would one handle reads like the ones that
>> occur in our application:
>>
>> (1) seek(position);
>> (2) readUTF() - read a key value.
>> (3) readInt() - size of the data associated with the data.
>> (4) .....
>>
>> We need to perform little reads before we know what the result is.
>>
> This may not be a good candidate. Is this a sequential file or do you know
> the file position of data you will need in the future? (in order words, does
> the file position for a read depend on the previous read?)
>
>  So far we were doing buffered reads and then working with the data in to
>> memory. To convert this into true AIO w/o blocking the application thread,
>> would involve some convuluted programming. Is this the norm? Is my
>> understanding correct as far as the programming paradigm is concerned? Are
>> there any samples anyone could share with me that helps me understand this
>> better?
>>
>>  Yes, this is the programming model. You either wait for the I/O to
> complete or else you are notified via a completion handler. The sample
> directory doesn't have examples using AsynchronousFileChannel yet (if anyone
> would like to contribute same that would be great).
>
> -Alan.
>
> PS: Did you track down that RandomAccessFile#close problem that you think
> might be a regression in the nio2 builds?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20081126/a106173c/attachment.html