Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: spawning a child by double forking
Summary: Can you say, "memory hog?"
Message-ID: <12376@bloom-beacon.MIT.EDU>
Date: 2 Jul 89 07:15:19 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 37


  Thus far, two people have suggested that one way to prevent zombie
processes from building up is to fork twice instead of once when
starting a child -- the child of the first fork forks again and then
immediately exits.  The "grandchild" which results is inherited by
init, which takes care of cleanup, and the parent therefore doesn't
have to worry about cleaning up.

  While this will accomplish the started purpose, I am not convinced
at all that it is the correct solution to the problem.  First of all,
it is quite possible at some point in the future development of the
program (if not now) that the parent will wish to know when children
exit.  If you implement this grandchild system throughout the code,
it'll probably be a bitch to modify things to keep track of how things
happen.  This is not a major problem if you are careful to isolate
functionality (we wouldn't want the whole program to be infected with
functionality, after all :-), but how many programmers really are
careful with something as mundane as starting a child :-)?

  Second, let's say that my program has a 512k binary image.  I fork
the first time, and I'm taking up a meg of memory.  I fork again, and
I'm taking up a meg and a half.  Granted, this memory usage only stays
around for a second (if that); however, on my workstation I am quite
often within a meg of my memory limits, and this could very well push
me over.  Also granted, on some architectures the forked processes
will share the text segment with the parent.  So what -- you shouldn't
count on this because it is far from portable.  It is bad practice to
implement a solution which will take one and a half times the
necessary amount of memory just because it eliminates the need for a
call to signal() and a three-line (if that) signal handler.

  Just my two cents....

Jonathan Kamens			              USnail:
MIT Project Athena				432 S. Rose Blvd.
jik@Athena.MIT.EDU				Akron, OH  44320
Office: 617-253-4261			      Home: 216-869-6432