NIO2 async threading

[David M. Lloyd]

On 06/14/2008 08:39 AM, Alan Bateman wrote:
> 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.

Ah, but this is the point of Exceutors.  The user wants control over the
Executor policy because the user knows more than the framework does.  If
the user wants to devote a 24-thread pool on a 64-core system, that's their
business - they have a good reason for it.  By duplicating this policy in
NIO, we've taken a step backwards - the point of Executors is to *remove*
this policy from the frameworks, not to mention taking away a lot of
flexibility.

> 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.

It is a fact of life in the modern Java world that services depend on one 
another.  Java developers by now should have a reasonable expectation that 
if B depends on A, then A must be started before B, and B must be stopped 
before A.  I don't consider this to be a problem.

I don't think it's wise to babysit the user in this regard.  Anyone using 
NIO, will know enough not to do this sort of thing by definition.  To 
paraphrase Stroustrup, this is a technical solution to a social problem.  I 
think it is more reasonable to simply use an Executor and explain the 
contract in the documentation.  The user might have a good reason - testing 
comes to mind - to use an unusual Executor implementation.  Believe me, 
there's nothing NIO users love doing more than testing. :-)

> 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).

One could argue that on social grounds, yes - not on technical grounds. 
The current solution solves the social problem, but causes technical 
limitations - this is a red flag to me.

> 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.

I hope you consider these points.

- DML