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: Friday, June 13, 2008 12:55:11 PM
Subject: Re: NIO2 async threading

Rob Butler wrote:
> Hello,
>
> I was wondering how threading would work for asynchronous channels?  Since callbacks are invoked to perform all reading/writing that work will always take place in threads controlled by the async provider, right?  Is there any standard way to control how many threads are in use?  To set the thread type (daemon, non-daemon)?  To set the thread names?
>
> Rob
>
>
>      
>  
[ moving to nio-discuss (if okay with you) as there are folks interested 
in this area that don't subscribe to the -dev mailing list ]

The class to check out is AsynchronousChannelGroup. There you will see 
how to configure the ThreadFactory, number of threads, etc. If you see 
anything missing or have comments please let us know.

-Alan.

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.

Thanks!
Rob