Path: utzoo!attcan!uunet!samsung!sdd.hp.com!ucsd!ucbvax!husc6!cmcl2!stealth.acf.nyu.edu!brnstnd
From: brnstnd@stealth.acf.nyu.edu
Newsgroups: comp.unix.questions
Subject: Re: How to terminate a child process without interfering a parent process
Message-ID: <845:May2718:47:2590@stealth.acf.nyu.edu>
Date: 27 May 90 18:47:25 GMT
References: <24504.26542926@kuhub.cc.ukans.edu> <12932@smoke.BRL.MIL> <790:May2221:05:4490@stealth.acf.nyu.edu> <12960@smoke.BRL.MIL>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Organization: IR
Lines: 27

In article <12960@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <790:May2221:05:4490@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
> >The right way to deal with stdio is to fflush() whatever output streams
> >you've used, then fork(), then exit() in all cases where you don't exec.
> >(If signal handlers produce output, they should fflush() anyway.)
> 
> While I'm a big fan of proper use of fflush(), there is often no need
> to artificially invoke it before a fork(), which I why my advice took
> the form that it did.

Using fflush() before a fork() is never wrong in practice; it's the only
way to guarantee that the child can safely use stdio; and the possible
efficiency hit is miniscule compared to the fork() time. While there may
be a few exceptions, novices should learn fflush()-fork() rather than a
fork()-_exit() that will ``mysteriously'' lose output.

> Asynchronous signal handlers better not use stdio, as they may have
> interrupted an adjustment of some FILE structure which could then be
> in an inconsistent state.  I've seen this happen, although it's hard
> to produce on demand.

True. However, if a signal handler does produce output, then it should
fflush(). This is an interface rule, so it probably has some important
exceptions; but it's independent of whether you've correctly protected
your stdio routines with criticial sections.

---Dan