FileChannel implements InterruptibleChannel, help or hindrance?

[Brian Burkhalter]

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

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

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.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180228/034bd176/attachment.html>