On Fri, 8 Aug 2025 15:52:26 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> 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. I will note that when used in try-with-resources, making Process::close idempotent will not keep the streams from being closed twice. T-W-R will close the streams as declared thru T-W-R variables, delegating the close() down through the streams to the Process streams. Later, Process::close will close the underlying writers or streams, in some cases for the second time. The only place where idempotent will come into play is when called directly and then possibly later by T-W-R. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2263655091
