Async channels
Rémi Forax
forax at univ-mlv.fr
Wed Apr 22 14:28:59 PDT 2009
Alan Bateman a écrit :
> 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.
that why I don't understand why a AsyncChannelGroup (perhaps a different
implementation)
can't be used as a group for AsyncFileChannels.
>
>>
>> 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.
complexity == 1 boolean that already exist in the implementation.
public AsynchronousFileChannel newAsynchronousFileChannel(Path path,
Set<?
extends OpenOption> options,
ExecutorService executor,
boolean
shared, <--- shutdown on close if not
shared !
FileAttribute<?>... attrs)
>
> -Alan.
Rémi
More information about the nio-dev
mailing list