NIO2 async threading

[Alan Bateman]

David M. Lloyd wrote:
> :
> Interesting about the configuration issue mentioned in the javadoc 
> (b91) - is there a link to more information about the Executor 
> discussion? Specifically I'm curious why the implementation needs to 
> know the maximum number of threads.
It's not so much the maximum number of threads but rather that an 
implementation may have a subset of those threads dedicated to handling 
I/O events and dispatching to completion handlers that consume the 
result of I/O operations. In that case an application-supplied Executor 
without additional tuning parameters may not work -- eg: suppose the 
system supports 64 threads in hardware but the application supplies a 
thread pool that that has a maximum of 24 threads. As the provider 
implementation doesn't know anything about the Executor it is given it 
means it may not be able to determine how many threads it can dedicate 
to handling I/O events while at the same time allowing the thread pool 
to handle other tasks needed by the implementation. An application 
supplied Executor also creates a bunch of uninteresting complications. 
It may be shutdown at any time by the application, it may have been 
created with a bounded queue, etc. While the latter issues aren't too 
interesting there are other thread pool policy issues that can be 
sensitive to the operating system. For example, on Windows, it is would 
not be possible to use a thread pool that has keep alive enabled as it 
could cause random I/O operations to abort when the thread pool is 
trimmed back. All told, the approach that is currently used eliminates a 
bunch of issues but has the side effect that the thread pool is not 
accessible to the application (and so the application can't submit its 
own tasks - one could argue this is a good thing). That note in red is 
just a reminder that this isn't cast in stone and we need feedback on 
its usage. There is also API detail to resolve here as the map of 
parameters may be error prone. Finally, all this is really just a 
concern for the more sophisticated applications creating their own 
channel groups - for simpler usages the default group should provide 
reasonable defaults.

-Alan.