Redirection of child process output - c++

Question

I'm redirecting output from a child process:
int pipefd[2];
pipe(pipefd);
pid_t pid = fork(); /* Create a child process */
switch (pid) {
case -1: /* Error */
cout << "Uh-Oh! fork() failed.\n";
exit(1);
case 0: /* Child process */
close(pipefd[0]);
dup2(pipefd[1], 1);
dup2(pipefd[1], 2);
close(pipefd[1]);
execv(args[0], (char * const *)args);
cout << "execv() error" << endl;
exit(1);
default: /* Parent process */
close(pipefd[1]);
char buffer[1024];
size_t bytes_read = 0;
bytes_read = read(pipefd[0], buffer, sizeof(buffer));
if(bytes_read == -1) {
cout << "read() error" << endl;
exit(1);
}
close(pipefd[0]);
if(bytes_read > 0) {
buffer[bytes_read-1] = '\0'; // Overwrite the newline
}
int status, exit_pid;
while(true) {
exit_pid = waitpid(pid, &status, 0);
if(exit_pid == -1) {
cout << "waitpid() error: " << strerror(errno) << endl;
exit(1);
}
else {
return WEXITSTATUS(status);
}
}
}
This works fine when I ran it as an isolated piece of code. But when I integrate it into my multithreaded environment, a horrible thing happens: the read() calls somehow reads output of other threads of the parent process, as if it were the output from the pipe of the child process.
Anyone encountered such a thing?
I'm on OS X.

Answer 1

Well, I have a solution even though I don't completely understand why this happened.
But first, it should be clear that this behavior is neither normal nor expectable. A child process created with fork() does not inherit any running threads from its parent (so the unexpected output must come from the parent threads). And it has its own descriptor table. So when the child process calls dup2() to alter its output descriptors, that shouldn't have any effect on the threads in the parent process.
The problem occurred only in cases where execv() call failed. In those cases, I expected the termination of the child process to close all its file descriptors. But that didn't happen, or at least it didn't have the same effect as calling close() explicitly. So adding explicit close() calls after execv() solved the problem:
execv(args[0], (char * const *)args);
close(1);
close(2);
exit(1);
The close of the write-end descriptor of the pipe is what will cause the read operation on the read-end to receive 0, thus knowing not to read anymore.
However, I still don't know the following:
Why isn't the call to exit() in the child process equivalent to explicitly calling close() ?
Even if the pipe write-end isn't closed, why does reading from the read-end produces output of threads in the parent process, instead of blocking, or returning some error ?
If anybody can shed light on this, it will be appreciated.