NIO controls and deals with the selectors. Async IO is a part of that but is not the same thing. Async io means that if a write cannot be fully flushed. It will not block until it can be. NIO provides us the events to tell us that data is available in the socket. On Apr 19, 2014 4:56 AM, "Alon Bar-Lev" <alon.bar...@gmail.com> wrote:
> On Sat, Apr 19, 2014 at 10:58 AM, Emmanuel Lécharny <elecha...@gmail.com> > wrote: > > Le 4/19/14 9:45 AM, Alon Bar-Lev a écrit : > >> On Sat, Apr 19, 2014 at 10:38 AM, Emmanuel Lécharny < > elecha...@gmail.com> wrote: > >>> Le 4/19/14 9:13 AM, Alon Bar-Lev a écrit : > >>>> Hi, > >>>> > >>>> The mission of async is to avoid having threads at all, or at least > O(1). > >>>> > >>>> As you have underline internal/private low level channels for socket > >>>> processing, and public high level channels to communicate with > >>>> application, there should be a mechanism for library to request wake > >>>> up for these low level channels. > >>>> > >>>> Another option is to avoid using sockets at all within the > >>>> implementation and require application to manage the sockets and pipe > >>>> socket data into the library. > >>>> > >>>> I understand this is conceptional change than what we have now, but > >>>> this what will enable scale without abusing system threads or have > >>>> nondeterministic behaviour in high load. > >>> There are a few important things you have to know about async and > threads : > >>> - the extra cost for dealing with async connection is around 30%. That > >>> all but free > >>> - a standard system can easily deal with a few thousands of threads > >>> > >>> Now, unless you define what is "high load", I don't really see what > kind > >>> of advantage we can get with an async implementation. > >>> > >>> FTR, when MINA was initially created, it was because there was a need > >>> for a system supporting potentially ten of thousands of connections. Is > >>> that what you are targetting ? > >> Yes, using work threads that are derived per # of CPUs, no more. > >> I am far from the pure "Java" world... but if async IO is 30% > >> insufficient, maybe it worth to use libssh (C) and communicate with it > >> using single socket from java, delegating IO outside of java. > > IO are already delegated outside on Java. Eveything IO related is > > written in C and wrapped into Java class. > > > > The extra cost when using NIO is due to the management of SelectorKey > > lists (with the various steps involved when dealing with those lists). > > > > All in all, when it comes to process IO, Java does not really add some > > extra cost over a plain C implementation. It's not the same story when > > using NIO, especially when dealing with many concurrent connections. > > > > So I am confused... Java does not add cost to async IO, but NIO does? > While NIO is the only interface to Java async IO? >
