FileChannel implements InterruptibleChannel, help or hindrance?

David Lloyd david.lloyd at redhat.com
Thu Mar 1 14:57:01 UTC 2018


On Wed, Feb 28, 2018 at 12:00 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 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.

Yes please.  In general, interrupt handling in I/O and NIO has been a
problem for us, to the point where we have implemented utilities in
our thread implementation to defer interrupts over a block of code
e.g. a lambda.

> 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.

It would be nice if InterruptibleChannel could be deprecated and
completely neutralized across the board as its behavior has been much
more harmful than beneficial in every case I've ever encountered it.

But failing that, having _any_ remedy would be great.  It would
however be nice if there was some way for this to be activated by
default (system property?) instead of at each open site.  Maybe users
should have to opt-in to interruptibility rather than the other way
around; the amount of existent software which relies on interrupt to
close files seems like it must be vanishingly small.

-- 
- DML


More information about the nio-dev mailing list