On Sat, Apr 26, 2008 at 4:03 PM, freenetwork at web.de <freenetwork at web.de>
wrote:
> Uhm, membering we had some problems with nio some time (years) ago; what
> are the reasons to switch from io to nio again?
Why NIO:
*) Faster
FileChannel.read() use pread() on unix, which does not
change FD position. Thus need no explicit synchronization
and provide paralleled I/O on single file.
(On windows, sun.nio.ch.FileDispatcher do the locking
implicitly, while this provide no performance advantage,
this is no worse then the previous code.)
Why this is not a problem:
*) Use blocking I/O,
Blocking I/O don't have need any threading/pooling,
which is what bite NIO programmers most.
I have never look at the old code, but I *guess* that's
where the old problem laies.
(and the old code use TCP, IIRC, which some need extra
care in non-blocking nio)
In blocking mode, NIO is essentially the same as
traditional java.io, with byte[] replaced by ByteBuffer.
*) Very small, self-contained,
which does not likely to cause problem.
If you have other worries on this, please don't hesitate to speak up / ask.
Regards,
Daniel Cheng
