From: Yukihiro Matsumoto <matz@...>
Date: 2004-09-03T09:11:08+09:00
Subject: Re: ruby-dev summary 24054-24170

Hi,

In message "Re: ruby-dev summary 24054-24170"
    on Fri, 3 Sep 2004 00:15:23 +0900, Ara.T.Howard@noaa.gov writes:

|i guess open3 needs it (the 2x fork) because there the calling process does
|__not__ exit, in my code however, it does.  so the double fork is needed to
|'spawn a daemon process' and a single fork is o.k. to 'become a daemon'.
|sound correct?

When you understand the reason for double fork, things will be clear.

Processes will be zombies (half dead process during process
termination) until their parents call wait(2) for them.  A daemon is a
long living process, and should be detached from parent processes.  So
here's the trick.  When parent processes die, child processes will be
adopted to init (pid=1) which calls wait(2) for its adopted children,
so that they will no longer become zombies.  Double fork is worked
this way.

In open3, double forks are 1) first fork just to die to pass its child
to init, 2) second fork that eventually exec the command.  In daemon,
double forks are 1) the calling interpreter itself (it's dying in
daemon), and 2) the child process that become a daemon.

|it seems like there is never any harm in having a double fork
|though, is there?

So if I understand you correctly, yours have triple forks instead of
two.  One extra fork harms little.  Very small cost for an extra
process creation.

							matz.