How to terminate a child process without interfering a parent process

[brnstnd at stealth.acf.nyu.edu]

In article <12960 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> In article <790:May2221:05:4490 at stealth.acf.nyu.edu> brnstnd at 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