Yup yup, I've known about this and lamented it myself. I understand some of the justification...there's a lot of state changes that happen inside an NIO blocking call, and it would indeed be difficult to guarantee that the underlying fd is in the expected state. There's a lot of cases where thread interrupts can cause an InterruptedException to start propagating, so you don't really know where in the process you were at.
Ultimately, though, I think the problem in his post is really in MINA more than it is in the JDK libraries. Arbitrarily sending interrupts to threads is always a bad idea; there's so many ways it can muck up the normal flow of a program. It seems like the MINA folks don't know about this peculiarity of NIO channels, or they wouldn't do something like this. In JRuby, this peculiarity forced us to make nonblocking IO operations use select and friends rather than just using thread interrupts, and that's probably the better way to do it. It means we can't interrupt blocking file operations, but I don't think file operations are generally supposed to block. It means we can't interrupt blocking subprocess reads or writes, because process streams are not selectable...but that's a flaw in the Java subprocess APIs. In any case, I've long wanted to replace the JDK IO APIs we use with something build on jnr-ffi, and Wayne Meissner already has a pretty nice start at that in jnr-enxio: https://github.com/jnr/jnr-enxio It would take some work, but I think we could start replacing our use of JDK APIs (starting with JDK's *awful* subprocess APIs) using enxio, and not worry about the quirks in JDK's NIO impl anymore. - Charlie On Wed, Mar 7, 2012 at 11:56 AM, Stephen Bannasch <stephen.banna...@deanbrook.org> wrote: > Charlie, > > I have no idea if this is a problem in JRuby -- but I know you've done a > bunch of work integrating NIO -- and I thought this was pretty interesting. > > Shawn Pearce <spea...@spearce.org> the lead developer of jgit responded to > this email describing a problem using NIO and getting > java.nio.channels.ClosedByInterruptException exceptions: > > [jgit-dev] nio exception > http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01474.html > > In his response he references this blog post he wrote about a critical > failing in the design of the NIO API where NIO will close an open file > descriptor automatically during interrupt: > > Don't Assume You Know What's Best > http://blog.spearce.org/2010/05/dont-assume-you-know-whats-best.html > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
