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?
