ARM and thread interruption

[Joshua Bloch]

Mike,

This is a very good point! Thanks for bringing it up.  I do believe that ARM
blocks should "reassert" InterruptedException (via
Thread.currentThread().interrupt()) rather than suppressing it. Once pointed
out, it seems like a no-brainer to me. I'm strongly in favor of it, and will
do my best to make it happen (unless someone comes up with a reason that it
isn't a good idea).

           Thanks again,

           Josh

On Mon, Jun 28, 2010 at 4:46 PM, Mike Clark <mclark at apache.org> 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.   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
>
>