On Thu, 16 Oct 2025 09:56:09 GMT, Alan Bateman <[email protected]> wrote:
>> src/java.base/share/classes/java/lang/Process.java line 235: >> >>> 233: destroyForcibly(); >>> 234: // Re-assert the interrupt >>> 235: Thread.currentThread().interrupt(); >> >> I think this is still problematic as code after the t-w-r can't be >> guaranteed that the child has terminated. So I think it needs a loop that >> ends when waitFor completes without an exception (destroyForcibly would only >> be called on the first interrupt of course). > >> @AlanBateman can you comment on the possibility of looping indefinitely and >> not be interruptible if the OS process cannot be destroyed. > > AutoCloseable and Closeable.close are specified to release the resources. If > Process.close completes normally (no exception) then users should expect that > all resources have been released and the process has terminated. > > In the current proposal, and assuming no interrupt, close waits indefinitely > for the process to terminate. If close completes normally then you know the > process has terminated. Someone might put code after the t-w-r to delete > files or do other cleanup. It's similar to ExecutorService where close waits > for all tasks to complete. So I think this part is okay. > > If interrupted while waiting then close should continue to wait or throw. I > think the current proposal, to complete normally but leave the process > behind, is problematic and surprising. Having close throw (probably > IOException) is a bit problematic too as there isn't much you can do. We > regularly see libraries ignoring the IOException thrown by close, including > from writable streams where close is screaming that it was unable to flush > buffered bytes. So while it wouldn't be terrible to throw, it may be better > to keep close simple and be uninterruptible (meaning it would be complete > normally when the process terminates and with the interrupt status set). > Working through a few use-cases where you might use t-w-r with Process would > help to validate the direction Yes, that works fine as long as the OS can eventually terminate the process. I was conerned that the OS may not be able to destroy the process without external intervention and the application would look like it is hung in `Process.close()`. I've seen a few zombie processes on Linux that `kill -9` can't get rid of. The advice in that case is to manually kill the parent of the hung process so `init` can take over as the parent and reap the process status. The recent commit implements the loop to wait forever for the process to terminate; that covers the cases that can be setup with testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2437986275
