Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!FNALA.FNAL.GOV!HERBER
From: HERBER@FNALA.FNAL.GOV ("Randolph J. Herber, CD/DCD/SP, x2966")
Newsgroups: comp.sys.sgi
Subject: Re: Defunct messages and spawned processes
Message-ID: <910225114740.24e07268@FNALA.FNAL.GOV>
Date: 25 Feb 91 17:47:40 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 66

I attempted to respond to the original poster via e-mail.  It was returned to
me as undeliverable mail.  Because I think that some readers of this mailing
list may find the answer useful, I am sending it to mailing list.

Randolph J. Herber,
herber@fnalf.fnal.gov (also the acting FNAL postmaster).

+From:	SMTP%"Postmaster" 25-FEB-1991 10:08:50.34
+To:	<HERBER>
+CC:	
+Subj:	Undeliverable Mail
+
+Date:     Mon, 25 Feb 1991 10:08:39 CST
+From:     Postmaster@FNALA.FNAL.GOV
+Subject:  Undeliverable Mail
+To:       <HERBER>
+Comment:  Bad address -- <lkestel@louie.udel.edu>
+Comment:  	Address refused by receiver: <lkestel@louie.udel.edu> (550 (USER) Unknown user name in "lkestel@louie.udel.edu")
+
+Start of returned message
+
+  Date:    Mon, 25 Feb 1991 10:08:26 CST
+  From:    HERBER@FNALA.FNAL.GOV (Randolph J. Herber, CD/DCD/SP, x2966)
+  Message-Id: <910225100826.24e07268@FNALA.FNAL.GOV>
+  Subject: Re: Defunct messages and spawned processes
+  To:      lkestel@louie.udel.edu
+  X-Vmsmail-To: SMTP%"lkestel@louie.udel.edu"
+  
+  Hi!
+  
+  The answer to your first problem is that you have to collect your zombie
+  children's death certificates before they can be laid to their rest.
+  
+  The answer to your second question is that a window will not close until
+  processes that have open file descriptors to it close them.
+  
+  Those were the head lines.  Now the news in detail.
+  
+  In the kernel, there are two structures that are used to maintain a process's
+  context.  The process block is used to maintain the data that must be
+  resident at all times.  The user area is used to maintain the data that can
+  be swapped out or released after the process terminates execution.  When
+  a process terminates, the exit status data is stored into the process block
+  and the user area is released.  The process block is released only when the
+  parent of the process issues a wait(2) or wait3(2) system call to obtain this
+  information.  While a process is in this state, frequently, it is refered to
+  as a "zombie."  Sometimes, this status data is refered to as a "death
+  certificate."  If a parent process dies (terminates) before a child process,
+  the child is sent to the orphanage which is run by init, process 1.  Init
+  waits for the death of its children.  For its natural children, it spawns
+  (gives birth to) new copies of those children as needed.  This is governed
+  by /etc/inittab.  For the orphans, it just circular files the death
+  certificates as the accounting data that is written at the same time is handled
+  by the kernel.
+  
+  The second program in your chain of program inherits any open files from
+  its parent process, the first program in your chain.  What resources are
+  inherited from a parent is documented in fork(2). As the windows are normally
+  opened as stdin, stdout and stderr, these need to be closed by the child
+  to release the window.  You may need to release the control terminal data
+  from the process block as well.  For this I suggest that you research how
+  to write a daemon program.
+  
+  Randy Herber, fnalf.fnal.gov
+
+End of returned message


Brought to you by Super Global Mega Corp .com