NIO2 async threading

[Rob Butler]

> > :
> > Maybe either AsynchronousChannelGroup could have an additional setting, or the 
> read method on AsynchronousSocketChannel could have an additional parameter.  
> This parameter could set the 'wait for more data' delay.  If it were on the read 
> method a value of 0 (zero) could be passed if the request was complete, and a 
> non-zero value in milliseconds would be passed to wait for 'more data' before 
> releasing the thread to handle other requests.  This might improve performance 
> similar to temporary selectors.  Of course some R&D would be necessary to see if 
> it actually was beneficial or not.
> >  
> We probably need more feedback and experiences from people using the API 
> before considering anything like this. Jean-Francois can correct me, but 
> I believe his approach is a trade off to avoid the cost of 
> re-registering with the main Selector and re-dispatchinh/handing off to 
> continue the processing for the case that more data arrives within a few 
> seconds. The approach may not carry over as there isn't the equivalent 
> of a Selector that is managed by one thread. 

I believe he's looking to avoid the thread context switch, which could be useful in the async API.  Using a temporary selector is only an implementation artifact.

Rob