FileChannel implements InterruptibleChannel, help or hindrance?

David Lloyd david.lloyd at redhat.com
Sun Mar 4 23:15:46 UTC 2018


On Sun, Mar 4, 2018 at 11:10 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 01/03/2018 14:57, David Lloyd wrote:
>>
>> :
>> 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.
>
> Is that interrupting file I/O with FileChannel or do you mean the network
> channels? I wasn't involved in JSR-51 but I believe an important use-case at
> the time was to be able to interrupt tasks in a thread pool that may be
> blocked in socket operations. I'm less sure about FileChannel as file I/O
> operations don't usually block indefinitely, at least not without NFS or
> other networked file system.

Either one - it is sometimes very inconvenient for NIO to be making
assumptions about intended behavior on interrupt.  In the
SocketChannel case, we're generally using temporary selectors to
manage the blocking with a non-blocking channel underneath, which
allows us to unblock on interrupt but at the same time it allows the
program to make the decision as to what to do with the socket... as
long as the interrupt doesn't arrive at an inconvenient moment (or we
remember to defer interrupts over any critical sections).  For
example, we might be waiting for a long-running request on a
multiplexed channel, so the appropriate action might be to cancel the
just multiplexed request (as opposed to killing off the entire
socket).  In cases where it's a thread managing a shared socket (or
pipe), the correct action may be for the thread to simply ignore the
interrupt, or to recursively interrupt certain other threads and take
no other action (allowing for a more "graceful" cancellation).

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.

>> 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.
>
> The other aspect to InterruptibleChannel is asynchronous close, something
> that is really important for network oriented channels.

I agree that this is an important behavior.  This could be pushed down
to the individual channel types though.

-- 
- DML


More information about the nio-dev mailing list