Async channels

[Alan Bateman]

Rémi Forax wrote:
> :
> I think I don't understand the difference between an Executor and a 
> AsyncChannelGroup.
An AsynchronousChannelGroup encapsulates the mechanism for handling I/O 
events so that the mechanism can be shared by many channels (think I/O 
port or equivalent). It has a thread pool for handling I/O events and 
dispatching to the completion handlers for I/O operations invoked on 
channels in the group. Combining I/O with thread pools can be a complex 
area. In this API you create a group with a thread pool and that decides 
the configuration. The group takes ownership of the thread pool so you 
shouldn't submit your own tasks directly, attempt to shut it down, or 
use it for another group. The group defines its own shutdown methods 
that are similar to ExecutorService except of course that do additional 
work like releasing resources.

>
> Furthermore, there is currently no way to use the same Executor for 
> more that one
> AsyncFileChannel because closing the file channel will shutdown the 
> executor.
> I don't understand the purpose of this restriction.
The use-cases for AsynchronousFileChannel are typically database-like 
applications with concurrent I/O operations to different parts of the 
file. It's quite different to network I/O where you want to share 
resources between thousands of channels. Also the underlying mechanism 
can be very different (making it not feasible, in many cases, for a 
group to support both file and network channels at the same time). If 
thread identity is not a concern then you can ignore all this and use 
the simpler open method. Conceptually this means the channel is in the 
default group and so will share the default group's thread pool which 
does the right thing. Closing the channel are no side effects. Where 
thread identity is important then it does require that you create your 
own thread pool. That thread pool will be used exclusively for the file 
channel. If there is a big need in the future to be able to share thread 
pools in such cases then we could update the API but it does introduce 
complexity that we can avoid for now.

-Alan.