Async channels

[Rémi Forax]

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