ARM and thread interruption

[Peter Levart]

On Monday, March 14, 2011 03:02:11 am Joe Darcy wrote:
> Hello Mike.
> 
> After due consideration and after consulting with the concurrency mavens
> on the JSR 166 expert group, the JSR 334 expert group has decided it is
> sufficient for the specification of the AutoCloseable type to strongly
> warn against having AutoCloseable.close throw InterruptedException at
> runtime.  Additionally, javac and other compilers may warn against
> declaring an AutoCloseable.close method which throws InterruptedException.
> 
> Thank you for raising this issue; regards,
> 
> -Joe

What about InterruptedIOException?

see below...

> 
> Mike Clark wrote:
> > I am little concerned about ARM suppressing
> > java.lang.InterruptedException and thread interruption status.   When
> > a thread is interrupted, its interrupt flag is set to true until an
> > InterruptedException can be raised and the interrupt flag reset.  It
> > is notable that the interrupt flag is reset after an
> > InterruptedException has been raised, because then the only remaining
> > indication that an interrupt occurred is the presence of the
> > InterruptedException.  Now consider that in an ARM block, the
> > InterruptedException may be relegated to a collection of suppressed
> > exceptions.  In this case, today's existing code would not notice the
> > InterruptedException and thus may not notice that its thread was
> > interrupted, preventing the thread from taking its interruption code
> > path.
> > 
> > Of course this problem of exception priority is present amongst any
> > two exceptions that occur during ARM -- not just
> > InterruptedExceptions.  However, because InterruptedException plays a
> > special role in the runtime's threading model, I think perhaps this
> > particular case may be worth considering on its own.
> > 
> > Code which must be responsive to interruption might need to introduce
> > a third strategy: upon catching an exception, it could iterate over
> > the suppressed exceptions and search for an exception that is
> > instanceof InterruptedException.  If such an exception is present, the
> > code can assume that an interrupt occurred.  The problem with this
> > approach is a problem of ownership of the interruption policy of the
> > thread.  Before suppressed InterruptedExceptions, we could trust that,
> > in general, a InterruptedException would travel up to code that
> > implemented the thread's interruption policy.  

What about interruption of read/write and also close on IO streams? The javadoc for 
InterruptedIOException says:

Signals that an I/O operation has been interrupted. An InterruptedIOException is thrown to 
indicate that an input or output transfer has been terminated because the thread performing it 
was interrupted. The field bytesTransferred indicates how many bytes were successfully 
transferred before the interruption occurred.


Regards, Peter

> > Now the
> > InterruptedException may end up in a lower-level catch block, as a
> > suppressed throwable of some other type of exception.  And that catch
> > block may not even know to search for the InterruptedException, let
> > alone what to do with it.  That catch block may be in code that you do
> > not control.
> > 
> > One idea I was thinking about was having ARM blocks re-assert the
> > interrupt status on a thread if the ARM block knows that it suppressed
> > an InterruptedException.  This wouldn't stop InterruptedExceptions
> > from sometimes getting relegated to suppressed exceptions, but it
> > would at least give the thread a second chance to assert a new
> > InterruptedException at a later statement.
> > 
> > I am not sure exactly what to do about this particular issue.  I
> > realize this is all a bit of an edge case, but as someone who has
> > written (and fixed) a lot of thread-interrupt code, it does concern me
> > a little, and I wanted to at least see if anyone else thinks this an
> > issue worth discussing.
> > 
> > best regards,
> > Mike