AsynchronousFileChannel.open seems to miss AsynchronousChannelGroup

[Maxim Mossienko]

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.

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.

On Thu, Dec 15, 2011 at 5:21 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 15/12/2011 12:48, Maxim Mossienko wrote:
>>
>> Hi, All
>>
>> AsynchronousFileChannel.open() seems to miss AsynchronousChannelGroup
>> as parameter, the method accepts only ExecutorService.
>> When I invoke AsynchronousFileChannel.open with my own executor
>> service for many files, each time a new Iocp (AsynchronousChannelGroup
>> group implementation on Windows) instance is created with one thread
>> per request. If I read 1000 files, this will create 1000 of
>> short-lived threads. For such bulk file operation I created
>> AsyncChannelGroup with fixed thread pool and see no way to use it. It
>> looks like API problem.
>>
>> Best, Maxim Mossienko
>
> I can't tell if AsynchronousFileChannel is the right choice for your
> specific usage - are you reading these 1000 files sequentially or reading
> from arbitrary positions, perhaps concurrently on each file?
>
> In any case, AsynchronousFileChannel cannot be associated with an
> AsynchronousChannelGroup as there is no guarantee that an implementation
> could service both network and file events with the same I/O facility. You
> may ask why it couldn't use two different I/O mechanisms under the covers
> but this raises questions as to how threads should be split between them. So
> for sharing resources between AsynchronousFileChannel implementations then
> you either use the default thread pool (by invoking the open method that
> doesn't specify a thread pool) or you specify a thread pool and the thread
> pool will be shared.
>
> As regards the one thread you are seeing, this is an internal thread used to
> service the I/O completion port. The reason for it is because the thread
> pool you provide to AsynchronousFileChannel is unknown and so the
> implementation cannot make the assumption that it can use one of the threads
> to service events. If you had 1000 instances with a fixed thread pool of 1
> for example then 999 ports would not be serviced. That said, we could
> potentially do a better implementation so that when the same thread pool is
> used with several AsynchronousFileChannel instances that they share the I/O
> completion thread and the internal thread. That would likely help with your
> case.
>
> -Alan
>