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, 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 > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080428/3d08de2a/attachment.pgp>
