Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!sun-barr!texsun!texbell!merch!cpe!hal6000!iv
From: iv@hal6000.UUCP
Newsgroups: comp.unix.xenix
Subject: Re: Checking for new mail (and kill
Message-ID: <-1087514@hal6000>
Date: 1 Sep 89 19:02:00 GMT
References: <9834@multimax.Encore.COM>
Lines: 28
Nf-ID: #R:multimax.Encore.COM:9834:hal6000:-1087514:000:1337
Nf-From: hal6000.UUCP!iv    Sep  1 14:02:00 1989


/* ---------- "Re: Checking for new mail (and kill" ----------
Seth Robertson		seth@ctr.columbia.edu:
> Sure,  Modify checkmail so that does the following:
> 
> 	if (kill(ppid,0))
> 	  exit(1);
> 
> So every so often, it checks to see if its parent is around.  If
> it isn't, it performs honorable suicide.
|*------------------------------------------------------------
Jeff d'Arcy		jdarcy@encore.com
>> This is an approach I'd tried earlier (I used SIGCHLD, actually) and
>> it worked OK, but I wasn't comfortable with the possibility that the
>> parent might try to do something with the signal instead of dropping
>> it.  That's when I thought of comparing initial vs. current PPIDs.
\* End of text from hal6000:comp.unix.xenix ------------------

Actually, "kill(ppid,0)" does NOT send a signal to `ppid'.  It merely 
goes through all the checks for errors, and then returns OK / E???? .
It's a great way of checking to see if a process still exists.  We use
such checks in resource locking code (is the owner of the lock still
running?)  No more dead lock-file problems.
----
IV  (aka John Elliott IV)	 Domain: iv@hal6000.Tandy.COM
Tandy Systems Software		   UUCP: ...!texbell!letni!hal6000!iv
900 Two Tandy Center		     or: ...!decvax!microsoft!trsvax!hal6000!iv
Fort Worth, TX 76102		  Phone: 817/390-2701; 9:30am-6:00pm CST, M-F