Agreed with the below, this is very unlikely to cause problems, either in terms of bugs or in terms of free JVM compatibility (on unix, implementation of FileChannel.read(long, buffer) is a trivial pread wrapper).
On Saturday 26 April 2008 14:40, Daniel Cheng wrote: > On Sat, Apr 26, 2008 at 4:03 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 > _______________________________________________ > Devl mailing list > [email protected] > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >
pgp6w6bQeX18e.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
