in reply to Fork Causing <defunct>

...would that make sense in this context however?

Why not? What's wrong with having the parent wait for its children?

In case of doubt where/when to wait, set up a $SIG{CHLD} handler that reaps any child as it dies.

Replies are listed 'Best First'.
Re^2: Fork Causing <defunct>
by owen (Initiate) on Mar 18, 2010 at 16:56 UTC
    It seems odd as the child is already waiting for the parent process to die. If they both wait for each other, won't that be infinite?

      The child cannot wait for the parent. That is not how it works.

      The child can, however, "divorce" itself from its parent and be adopted by init (process 1), as is stated in another part of this thread.

      If you are getting a defunct process, either you are not waiting for your spawned process, or your program has grandchildren that the child process is not reaping.

      When the process shows up as defunct in the process table, that process has finished, and the operating system is just keeping a data structure around with the exit information so that the parent process can read it if it cares. The parent process must deal with its children, either by waiting for it, informing perl / the os to ignore it (%SIG and perlipc), or exiting your program and letting the OS handle it.

      It is said that "only perl can parse Perl." I don't even come close until my 3rd cup of coffee. --MidLifeXis

        To have the child waiting on the parent looks like this:
        }elsif($pid == 0){ # This is the child, it will log when the parent is done + + while(!&parentIsDead){sleep(10);} # &finalLog($traceFileToLog); + + &finalLog($traceFileToLog, $initialString); exit(0); sub parentIsDead { if(getppid()==1){ return 1; } return 0; }

      A child can't wait(2) for its parent...