FileChannel implements InterruptibleChannel, help or hindrance?

[David Lloyd]

On Mon, Mar 5, 2018 at 7:39 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 04/03/2018 23:15, David Lloyd wrote:
>>
>> :
>> 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.
>
> Interrupting a blocking I/O operation on a file or socket and leaving it
> open is highly problematic. Early JDK releases attempted to do this with
> so-called "interruptible I/O". Aside from not being feasible everywhere, you
> can't leave a file or socket connection in an inconsistent state where it
> may continue to be used. There are a slew of scenarios where bytes can be
> lost. It took use several major releases to finally remove all the issues
> caused with the JDK 1.0 era mechanism and I don't think we want to go back
> there again.

In all cases, exceptionless partial reads are a perfectly
safe/acceptable outcome for interruption.  In fact if the API were
being designed from scratch today, I might even argue that a
zero-bytes read/write would be the preferred behavior when operations
are entered in an interrupted state.  Either way I don't see how
anything in the API (as I've proposed it) could possibly lead to data
loss.  AFAICT the biggest API risk is the use of bytesTransferred in
InterruptedIOException, which in retrospect was probably not a great
idea.

Beyond API effects, at an implementation level, is there some facet to
the interruption mechanism itself that would lead to data loss?  OS
signals and special FD types (like eventfd) are two implementations
which should be immune to any problems of this sort on *nixes.  Is
Windows the main problem here?

-- 
- DML