NIO2 async threading

[Rob Butler]

----- Original Message ----
> From: Alan Bateman <Alan.Bateman at Sun.COM>
> To: Rob Butler <crodster2k at yahoo.com>
> Cc: nio-discuss at openjdk.java.net
> Sent: Saturday, June 14, 2008 10:09:40 AM
> Subject: Re: NIO2 async threading
> 
> Rob Butler wrote:
> > :
> > Thanks, that really cleared things up.
> >
> > Jean-Francois has done lots of R&D with NIO.  He's found that using temporary 
> selectors and doing IO operations on the same thread (only when waiting briefly 
> for more data to complete a request) leads to higher throughput (and I would 
> suspect lower latency) than using separate 'worker' and 'IO' threads.  
> (http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html) 
> Such an approach wouldn't be possible with Async NIO, would it?  I.E. you get a 
> callback to tell you about new data arrival, but there is no way to hang out 
> (and momentarily block in the callback thread) waiting for more data, is there?
> >
> > If that's the case, while dealing with selectors is a pain, the existing NIO 
> API may ultimately be faster and have lower latency than the NIO2 async API's.  
> Please point out anything I may have missed that would make this not the case.
> >  
> It's probably best not to jump to any conclusions here. The underlying 
> implementations are very different. For the scenario you describe, if a 
> completion handler is consuming the result of a read operation and it 
> initiates another read operation (because its buffer has sufficient 
> remaining space, or due to a short-read) then its handler will execute 
> immediately on the current thread if there is data available (no context 
> switch, no additional latency). 

That should probably be more explicit in the Javadoc.  These are the exact kind of threading behaviors people will want more info on.

> There isn't direct support to "bet" on 
> data arriving in a few seconds but as there may be several threads 
> polling events from the kernel then there shouldn't be any delay when 
> the data arrives (note that this is very different to the existing API 
> where a single thread polls with the Selector). 

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.

> Jean-Francois and I talk 
> very regularly. He's on this mailing list and may wish to say something 
> about the work he has done so far to port Grizzly to the new API. I 
> believe there is still work to do so I don't think there is performance 
> numbers to share yet. When he is done perhaps we can get him to write up 
> an equivalent tricks 'n tips for the new API :-)

That would be great!  I've found his research very helpful.