NIO2 async threading

[Alan Bateman]

David M. Lloyd wrote:
> :
> 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.
There isn't any intent to duplicate this policy - sorry if it came 
across that way. At the moment the parameters to construct the Executor 
are provided by the application when creating the channel group. At the 
same time the I/O implementation needs some knowledge of the concurrency 
as it controls the underlying event or completion ports where tasks wait 
on events. As I said, it's an open point (hence marked in red) where we 
were looking for feedback so thank you for taking time to consider it.

>
> :
> 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. :-)
You'd be amazed by some of the code attached to bug reports :-) As 
always, it is hard to know how much rope to give the developer. Given 
that channel groups are intended for sophisticated applications you may 
be right to ignore these concerns. In the original draft, we had wording 
on taking care when configuring the thread pool.

Alan.