Windows: A pipe() replacement whose ends are not inherited to children.
commit897bb8cb2c2ce6b73038bd8d4106fde079a09cf6
authorJohannes Sixt <johannes.sixt@telecom.at>
Fri, 7 Dec 2007 21:05:36 +0000 (7 22:05 +0100)
committerJohannes Sixt <johannes.sixt@telecom.at>
Mon, 23 Jun 2008 11:40:31 +0000 (23 13:40 +0200)
tree80307ea3202fd6faa95d35873945860f23e415f1
parentf1a4dfb85a432ae338d162179eaac5d50154fbeb
Windows: A pipe() replacement whose ends are not inherited to children.

On Unix the idiom to use a pipe is as follows:

    pipe(fd);
    pid = fork();
    if (!pid) {
        dup2(fd[1], 1);
        close(fd[1]);
        close(fd[0]);
        ...
     }
     close(fd[1]);

i.e. the child process closes the both pipe ends after duplicating one
to the file descriptors where they are needed.

On Windows, which does not have fork(), we never have an opportunity to
(1) duplicate a pipe end in the child, (2) close unused pipe ends. Instead,
we must use this idiom:

    save1 = dup(1);
    pipe(fd);
    dup2(fd[1], 1);
    spawn(...);
    dup2(save1, 1);
    close(fd[1]);

i.e. save away the descriptor at the destination slot, replace by the pipe
end, spawn process, restore the saved file.

But there is a problem: Notice that the child did not only inherit the
dup2()ed descriptor, but also *both* original pipe ends. Although the one
end that was dup()ed could be closed before the spawn(), we cannot close
the other end - the child inherits it, no matter what.

The solution is to generate non-inheritable pipes. At the first glance,
this looks strange: The purpose of pipes is usually to be inherited to
child processes. But notice that in the course of actions as outlined
above, the pipe descriptor that we want to inherit to the child is
dup2()ed, and as it so happens, Windows's dup2() creates inheritable
duplicates.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
compat/mingw.c
compat/mingw.h