FileChannel implements InterruptibleChannel, help or hindrance?

Alan Bateman Alan.Bateman at oracle.com
Mon Mar 5 13:39:29 UTC 2018


On 04/03/2018 23:15, David Lloyd wrote:
> :
> The file case is no different. The challenge with files is that it's
> generally difficult or impossible (on most OSes) to move the blocking
> to a select-ish layer.  From the perspective of user programs, it
> would have been better to either return a partial read (if some data
> was read before the interrupt) or throw an IOException (something like
> InterruptedIOException but without the bytesTransferred field, which
> leaves the interrupted state set but also leaves the channel open)
> which would allow the user to decide how to proceed.  This allows
> interruption to fulfill its primary mission - to ensure the thread
> isn't blocked so it can respond appropriately.  But it also gives more
> options about how the actual user code can proceed.
Interrupting a blocking I/O operation on a file or socket and leaving it 
open is highly problematic. Early JDK releases attempted to do this with 
so-called "interruptible I/O". Aside from not being feasible everywhere, 
you can't leave a file or socket connection in an inconsistent state 
where it may continue to be used. There are a slew of scenarios where 
bytes can be lost. It took use several major releases to finally remove 
all the issues caused with the JDK 1.0 era mechanism and I don't think 
we want to go back there again.

-Alan


More information about the nio-dev mailing list