On Jun 26, 2005, at 7:16 PM, nobu.nokada / softhome.net wrote:
> At Mon, 27 Jun 2005 00:53:04 +0900,
> gwtmp01 / mac.com wrote in [ruby-talk:146522]:
>
>> If the goal is simply to prevent zombie processes, then  
>> Process#detach
>> should just do a double fork.  Here is an implementation of that
>> technique along with a couple other issues that are common when
>> creating a detached process (a daemon in Unix terminology):
>>
>
> Open3 does it and it makes impossible to get the result of the
> given command.

It depends what your goal is.  If you want to start a child
process and capture output, interact with the process via IO,
or wait for the exit status you've got a variety of things to work with:

     Kernel#`
     Kernel#system
     IO.popen
     Open3#popen3

But if you aren't interested in capturing the output and/or
exit status of the children you probably are going to work with
fork/exec to establish a more typical "deamon" behavior where the
daemon process is completely disassociated from the parent process.
This is where the Process#daemon method I posted would be helpful.

Process.detach is a bit strange.  It is used *after* the child
has already been forked, at which point there is nothing much that
#detach can do other than periodically wait on the child.  It can't
double fork because the new child will be a sibling of the previous
child and not a parent.

It just seems strange to use Process.detach instead of some other
combination that avoids the whole busy wait problem in the first
place.


Gary Wright