On Sun, 14 May 2023 17:28:33 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> Trying to understand this, and the scope of the problem: > > * Parent process opens "in" pipe. > > * Now owns read and write end of pipe. > > * Parent forks jspawnhelper. > > * jspawnhelper inherits handles. Now there are four open file descriptors > to this pipe. > > * Parent dies and releases its handles > > * jspawnhelper gets thrown out of its first "readFully", but enters the > next "readFully". It still owns both read and write end of the pipe. So it > will wait endlessly. We only get an EOF from a pipe read when all write ends > are closed. > > Is this the problem? Exactly, except that `jspawnhelper` doesn't even gets "thrown out" of the first `readFully()` it is waiting in, as long as there's an open write end for that pipe. > I wonder whether the parent may not have the same problem at the other end. > It may be prudent to close the child's ends of the three pipes right after > calling startChild() > (https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#LL681C17-L681C27). But the parent first only reads from `fail[0]` (both, the keep-alive message as well as the EOF on a successfull `execvp()`). And it already closes its write end of that pipe before doing the first read, see: https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#L698 Once it made sure the child process was executed, it also closes the corresponding ends of the in/out/err pipes which connect it with the child process (see https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#L738-L740). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1547811575
