On Fri, 8 Aug 2025 10:45:47 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updates from review comments: >> - Editorial improvements to javadoc >> - Exceptions that occur closing streams are quietly logged >> to the java.lang.Process system log as DEBUG >> - The prototype code attempting to wait for process exit is removed, >> it provided marginal benefit and raised complexity due to interrupt >> handling >> - Test updates for racy test cases that are not errors > > src/java.base/share/classes/java/lang/Process.java line 655: > >> 653: quietClose(outputWriter != null ? outputWriter : >> getOutputStream()); >> 654: quietClose(inputReader != null ? inputReader : >> getInputStream()); >> 655: quietClose(errorReader != null ? errorReader : >> getErrorStream()); > > Async close of process stream is a complicated here. Do you have a summary on > how it behaves on both Unix and Windows? I'm thinking about the deferred > close code in particular. (I don't have an issue with close throwing away the > exceptions, I'm just not 100% sure that async close is reliable in the first > place). > >> Closing an already closed stream usually has no effect but is specific to >> the stream. > > I wonder if we could specify Process::close to be idempotent. That would mean > we couldn't attempt to re-close if a first close of stream failed or had some > other side effect. That would remove any question about behavior without having to delve into the details of every stream close. Down at the bottom of every process stream is a FileDescriptor holding either an fd (Linux) or a handle (Windows). This is true for all the redirects whether to files, pipes, or inherited (stdin, stdout, stderr). The FileDescritor.close method is very careful to impotently close and reset the fd/handle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2263336699
