executor for AsynchronousFileChannel.open()

[Zhong Yu]

Thanks Alan. You are right, in the context of heavy I/O operations, my
concern about threading overhead of the lightweight tasks is
overblown.

I'll simply use the default thread pool with unbounded number of
threads. However one problem is that these threads never expire

    class sun.nio.ch.ThreadPool
        static ThreadPool createDefault() {

            ExecutorService executor =
                new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                   Long.MAX_VALUE, TimeUnit.MILLISECONDS,
                                   new SynchronousQueue<Runnable>(),
                                   threadFactory);

After peak load, the extra threads will stay forever. Some users might
find that unsettling. Shouldn't we set a human-scale timeout, like 60
seconds?

Cheers,
Zhong Yu

On Tue, Apr 10, 2012 at 5:15 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 02/04/2012 22:41, Zhong Yu wrote:
>>
>> :
>> Let's say my completion handlers do nothing but compute checksums of
>> file content. In that case, can I use a ThreadPoolExecutor with
>> maximumPoolSize == Runtime.availableProcessors()? Is there any
>> assurance that no other tasks will be submitted to this executor?
>
> The reason for the wording in the open method is to allow for highly varied
> implementations. For example, on Windows XP you may observe tasks being
> submitted to the thread pool to initiate I/O operations for cases where you
> attempt to initiate on non-pooled thread. On newer versions of Windows you
> don't observe this and you will only see tasks that are handling completion
> events and invoking your completion handlers. On Solaris/Linux/Mac then the
> default implementation of AsynchronousFileChannel isn't making direct use of
> kernel facilities at this time so you will observe tasks that last for the
> duration of the I/O operation. Hopefully it should start to become clear
> that it's not easy to provide general advice on the maximum pool size. You
> suggestion to start with Runtime.availableProcessors should be okay but I
> would suggest monitoring it to see how much concurrency you actually get. It
> may be that the I/O is too slow compared to the checksum computation, in
> which case you may not observe too many threads executing completion
> handlers concurrently.
>
> -Alan.