This does work for the test provided. The interrupted thread fails on the closed channel, but other theads continue to run on reopened channel.
The problem with the non-interruptible I/O is the jdk8 backport issue. There is no way to use the non-interruptible read without loading new classes at start up (reflection or method handles.) I could check version and use different paths on JDK-9 and JDK-8. Other suggestions? — Jim > On May 19, 2016, at 10:46 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 19/05/2016 14:03, Jim Laskey (Oracle) wrote: >> On 32 bit, a shared jimage channel closed by an interrupted thread >> (ClosedChannelException) disrupts other threads sharing jimage. Fix is to >> reopen channel on not interrupted thread. >> >> http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8156602 > Does this work? The interrupt status isn't cleared so I would expect the > second and subsequent reads to fail and so hit the retry limit. > > In generally them I'm uneasy about this approach and would prefer if we used > non-interruptible I/O. I don't mind working on it if you'd like to get rid of > it. > > -Alan
