AsynchronousFileChannel.open seems to miss AsynchronousChannelGroup

[Alan Bateman]

On 15/12/2011 16:48, Maxim Mossienko wrote:
> IMO the fact that AsynchronousFileChannel cannot be associated with an
> AsynchronousChannelGroup via AsynchronousFileChannel.open is only due
> to historical reasons because if caller does not provide
> ExecutorService (pass null) then system default
> AsynchronousChannelGroup is used. I only ask to add
> AsynchronousFileChannel.open method that accepts
> AsynchronousChannelGroup (created via AsynchroneousChanelGroup.with...
> method) instead of ExecutorService. It looks like reasonable change.
It's not historical. The reason it works with the default thread pool is 
because the implementation knows the type of thread pool and so can 
dedicate threads to service the completion port.

>
> I enqueue 1000s file reading requests to thread pool of different
> size, using the same pool for async operations. I expected to adapt
> pool parallelism to different drive / OS combinations. E.g. for Mac on
> SSD, async read requests and thread pool size>= 2 I observe 50%
> better results than just reading the files sequentially.
> Unfortunately, current async file read implementation on Windows can
> not be constrained with such pool without API change.
>
Are you just doing a sequential read and are the files only open for a 
very short time? I would be interested to see if you get the same 
results if you use the default thread pool which you can control via the 
java.nio.channels.DefaultThreadPool.* properties.

-Alan.
||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111215/1a8c79b1/attachment.html