On Wed, 6 Aug 2025 15:46:18 GMT, Roger Riggs <rri...@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`. > > 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). The faulty implementation using waitFor is removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2261555962
