FileChannel implements InterruptibleChannel, help or hindrance?
Alan.Bateman at oracle.com
Wed Feb 28 18:00:42 UTC 2018
As we all know here, FileChannel implements InterruptibleChannel so it's
asynchronously closeable and interrupting threads doing I/O operations
on a file channel cause it to be closed.
I've never been comfortable with the FileChannel being closed by
Thread.interrupt and I'm wondering whether it would be worth providing a
way for file I/O operations to not being interruptible. A case in point
is class loading from the jimage container file, another is class
loading from modules exploded on the file system. The former hacks into
FileChannel implementation to prevent closing and spurious
NoClassDefFoundErrors, the latter is pondering doing the same. We also
have Files.readAllBytes and Files.newXXXStream ultimately using a
FileChannel where a thread interrupt might cause usage to fail with
One potential approach is to add an OpenOption (maybe
StandardOpenOption.UNINTERRUPTIBLE) that can be specified to
FileChannel.open. This seem preferable to providing a way to toggle
interruptibility dynamically, esp. in cases where a FileChannel is used
by several concurrent threads. There are wider scope ways to do this too
but it would mean re-visiting InterruptibleChannel and its base
implementation in the spi package with potential knock on impact in
other areas of the API.
More information about the nio-dev