How ReadableByteChannelImpl Handles Interrupts

Question

I am trying to use Channels.newChannel for an InputStream wrapper to support interrupts. I saw conflicting information about whether this would work. Including comment in ReadableByteChannelImpl: // Not really interruptible

In ReadableByteChannelImpl before making a blocking call to InputStream.read , AbstractInterruptibleChannel.begin is called, which sets up a new Interruptible with sun.misc.SharedSecrets.getJavaLangAccess().blockedOn , which will close the completed InputStream.

 protected final void begin() { if (interruptor == null) { interruptor = new Interruptible() { public void interrupt(Thread target) { synchronized (closeLock) { if (!open) return; open = false; interrupted = target; try { AbstractInterruptibleChannel.this.implCloseChannel(); } catch (IOException x) { } } }}; } blockedOn(interruptor); Thread me = Thread.currentThread(); if (me.isInterrupted()) interruptor.interrupt(me); } 

Is it true that if an InputStream throws an IOException from a blocked read request, if it is closed by another thread, then ReadableByteChannelImpl will make the interrupted stream intermittent?

Answer 1

Yes, to a large extent. The Channels.newChannel() adapter returns an instance of ReadableByteChannelImpl if the stream is not a FileInputStream ; in this case, it returns a FileChannel , which is also aborted.

When you receive a ReadableByteChannel , the code that you have already learned suggests (and checks, confirms) that the underlying InputStream closes asynchronously interrupt() on a thread blocked in reading.

This may depend on the implementation of InputStream , but implementations included in the Java Java runtime will respond to asynchronous closures by throwing an exception in the read stream. The specific type of exception will vary.