On Fri, 17 Oct 2025 01:36:49 GMT, Roger Riggs <[email protected]> wrote:
>>> @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. Thanks for the update. I have sympathy for zombie scenario but it would be too surprising for close to completely normally in that case. So I think the updated proposal looks reasonable and we should see what we can do to improve diagnosability when blocked indefinitely in close. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439476760
