FileChannel implements InterruptibleChannel, help or hindrance?

Brian Burkhalter brian.burkhalter at
Wed Feb 28 19:22:35 UTC 2018

On Feb 28, 2018, at 10:00 AM, Alan Bateman <Alan.Bateman at> wrote:

> One potential approach is to add an OpenOption (maybe StandardOpenOption.UNINTERRUPTIBLE) that can be specified to 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.

Providing dynamic toggling of interruptibility would introduce complexity that we probably don’t want. The OpenOption approach is appealing but the InterruptibleChannel specification does not appear to admit much flexibility on this point:

[Interrupting a thread] blocked in an I/O operation on an interruptible channel […] will cause the channel to be closed, the blocked thread to receive a ClosedByInterruptException, and the blocked thread's interrupt status to be set.

Other solutions as you observed would however have much broader impact.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nio-dev mailing list