Async channels
Alan Bateman
Alan.Bateman at Sun.COM
Wed Apr 22 01:34:19 PDT 2009
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.
More information about the nio-dev
mailing list