fork and pipe problem
Duncan Roe
duncanr at optimation.com.au
Mon Feb 24 12:29:37 EST 2003
On Sat, Feb 22, 2003 at 06:22:44PM +1100, Alex Pollard wrote:
> Hi,
>
> I'm debugging some software on two machines. One is an athlon 686 RedHat 8.0
> with kernel 2.4.18-14, the other a pentium with RedHat 7.1 and kernel
> 2.4.9-31
>
> The code works fine on the athlon without the fcntl(), but it is required for
> the pentium.
>
> if (!(childPid = fork())) {
> // close stdout and dup the writing end of the pipe
*** So *close* STDOUT_FILENO before the dup2()
> if (dup2(childToParentPipe[1],STDOUT_FILENO)==-1) {
> fprintf(stderr, "Failed to dup2 in proc = %d\n",(int)getpid());
> }
> //fcntl(STDOUT_FILENO, F_SETFD,FD_CLOEXEC);
*** You *never* want to to that. It will close the pipe, if the dup2 call worked
>
> // close unused end of pipe
>
> ::_close(childToParentPipe[0]);
>
> fprintf(stderr,"execing on ");
> fprintf(stderr,"%s -p %s -r %s \n",command,portString,theDirector.url()
> );
> if (execl(command,command,"-p",portString,"-r",theDirector.url(),NULL)<0)
> { fprintf(stderr,"exec on %s -p %s -r %s failed with error
> %d\n",command,portString,theDirector.url(),errno ); delete this;
> exit(-4);
> }
>
> }
>
> Without the fcntl() on the athlon the child process's output to STDOUT is
> received at the parent's end of the pipe. Without the fcntl() on the pentium,
> the child process's output appears in the terminal, but there is no error
> reported for the dup2() or anything else.
>
> But the problem with including fcntl() in either version is that the parent
> never receives notification of data put into the pipe via a select call.
>
> I've found that
>
> fcntl(STDOUT_FILENO, F_SETFD,0);
>
> is equivalent to not using fcntl() at all.
>
>
> Is there some difference between how these kernels handle fork() and execl()?
>
> Also, is it OK for multiple child processes to use the same pipe to send data
> to their common parent? Or should there be a new pipe for each child? I'm
> ignoring the problem of zombie children for the moment.
>
> Alex
>
>
More information about the linux
mailing list