Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!amanue!oglvee!jr From: jr@oglvee.UUCP (Jim Rosenberg) Newsgroups: comp.unix.wizards Subject: Re: Sys V fork IS broken! Keywords: "What UUUUUUUUNIX meeeeans to meeeeeee..." Message-ID: <574@oglvee.UUCP> Date: 1 Aug 90 23:21:05 GMT References: <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP> <13435@smoke.BRL.MIL> <1990Jul28.195032.18746@watdragon.waterloo.edu> <1990Jul30.002642.18244@dg-rtp.dg.com> Organization: Oglevee Computer Systems, Connellsville, Pa Lines: 37 In <1990Jul30.002642.18244@dg-rtp.dg.com> rice@dg-rtp.dg.com (Brian Rice) writes: >And, of course, the kernel tells you why your fork failed: you get EAGAIN or >ENOMEM in errno. Not clear! In the V.3.2 man page for fork(2) it sez: EAGAIN Total amount of system memory available when reading via raw IO is temporarily insufficient. ENOMEM The process requires more space than the system is able to supply. The scenario causing all the ruckus is memory temporarily unavailable while doing a fork. Apparently ENOMEM is what you get when you run out of swap space. (The BSD man page mentions swap space explicitly for ENOMEM.) I agree with those posters who argue that out of swap space is a pretty grave condition; I would want my applications to shut down as gracefully as possible and bail the hell out. If we're out of swap space, it's just as likely to get worse as to get better. I would certainly *not* want to retry in this circumstance. But I think retrying when you're out of process table slots is pretty dubious too. That and the no-kernel-memory problem seem *both* to be covered by the same errno. I would say this is a flat out and out defect in which values of errno are returned by which circumstance. And the man page should say something more clear than that weird "raw IO" language. Raw IO??? If the system call doesn't distinguish between problems that *are likely* go away in a few seconds versus those that are of unpredictable duration, then yessiree folks, the kernel *IS DICTATING POLICY* -- and a most unfortunate one. If it won't let my application judge the severity of the error then the kernel is dictating the policy of making the application plan for the worst case -- when it may not have to. -- Jim Rosenberg #include --cgh!amanue!oglvee!jr Oglevee Computer Systems / / 151 Oglevee Lane, Connellsville, PA 15425 pitt! ditka! INTERNET: cgh!amanue!oglvee!jr@dsi.com / /