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