On Wed, 6 Aug 2025 14:38:59 GMT, Archie Cobbs <aco...@openjdk.org> wrote:
>> Can we simply restore the interrupt after `destroy()`?
>>
>>
>> } catch (InterruptedException _) {
>> try { destroy(); }
>> finally { Thread.currentThread.interrupt(); } // Restore the interrupt
>> }
>
>> Can we simply restore the interrupt after destroy()?
>
> That's the suggestion... but now I'm thinking the correct solution here is to
> just have `close()` declared to throw `InterruptedException` and not catch
> anything. Then we are leaving it up to the caller to decide what to do,
> rather than being forced to make an assumption one way or another.
>
> In practice, there seem to be two typical scenarios when shutting things down
> using methods that block and throw `InterruptedException` (e.g.,
> `ExecutorService.html.awaitTermination()`, `Process.waitFor()`, etc.):
>
> Scenario 1: You want to ensure everything is properly and completely shutdown.
>
> In this scenario you ignore `InterruptedException`s until each shutdown step
> fully completes: if any step throws an `InterruptedException`, you make a
> note of it, loop back around and restart that step. You don't return until
> all steps are complete. Just before returning, if you were interrupted at any
> point, you re-interrupt the current thread so the interrupt is not lost. You
> are optimizing for completeness.
>
> Scenario 2: You want to start shutting things down, but if you are
> interrupted, you want to immediately bail out.
>
> As soon as an interrupt occurs, stop trying to shut things down and return.
> You are optimizing for speed.
>
> The problem is that if `Process.close()` isn't declared to throw
> `InterruptedException`, then that makes it impossible to implement scenario 1
> (regardless of whether you re-interrupt the thread) because the caller has no
> way of knowing whether the process actually did terminate. And if you don't
> re-interrupt the thread, you also make it impossible to implement scenario 2.
>
> So in my estimation re-interrupting the thread is better than not
> re-interrupting the thread, but regardless of that, there is still a problem
> if `Process.close()` isn't declared to throw `InterruptedException`.
Indeed, the benefit of the attempt to be nice and not destroy the process too
quickly is almost immediately overcome by the complexity of dealing with the
side effects of the waitFor and the necessity to deal with interrupts both in
the implementation and in the caller. Especially in an attempt to do something
that the caller can do for themselves (calling waitFor).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2257605317
