ARM and thread interruption

[Mike Clark]

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