brnstnd@stealth.acf.nyu.edu (05/28/90)
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