On Wed, 6 Aug 2025 08:18:03 GMT, Volkan Yazici <vyaz...@openjdk.org> wrote:
> 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`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2257418786
