[MUD-Dev] Re: Technical C/C++ coding question

[Jon Leonard]

On Sun, Jun 14, 1998 at 07:57:38AM -0700, J C Lawrence wrote:
> On Sun, 14 Jun 1998 00:39:06 -0500 (CDT) 
> Katrina McClelan<kitkat at the486.bradley.edu> wrote:
> 
> > 	if(!fork()) { /* child copy starts here */
> >         kill(getpid(),SIGSEGV); /* this'll dump core */ 
> >         sleep(10); /* make sure it stops here */ 
> >         /* dead by here */ 
> >       }
> > 	/* parent continues unaware */
> 
>   1) No, you are not even slightly guaranteed that the child will have
> fully exited/cored by the end of the sleep.  Process schedulers are
> funny that way.  Call waitpid().  Be prepared for the child to have
> already exited and to have left the process table by the time
> waitpid() is run in the parent (WNOWAIT).  

If I read the code right, the sleep is in the child, to keep the child
from executing additional parent code.  I'd include an exit() after the
sleep, so that if the kill doesn't work (SIGSEGV blocked?), the child
doesn't do any damage.

That said, I'd use abort() instead of kill, and not bother with the sleep.
I'd keep the exit() because I'm paranoid, and some older OSes may return
from abort.  If the appropriate signal is precise, the sleep is useless
anyway.

>   2) Check for failure of the fork() and retry if needed.  On
> healthily running systems, fork() may well fail due to contention at
> the process table spinlock.  The Kernel will throw an error rather
> than queue the requests and guarantee success (common design decision
> for SMP kernels).  You should account for this.  

Failure to fork would be good to test for.  If you're willing to accept
a failure mode of no core file, the above code is find.  If not, you
should deal with core dump size limits, trapped signals, and current
directory issues.

>   3) You'd get slightly cleaner results if the child just immediately
> hung an alarm() and the parent killed the child.

I don't see any particular reason to do this.  It seems cleaner to me
to have the parent do nothing but the fork.

Jon Leonard