Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <13344@smoke.BRL.MIL>
Date: 11 Jul 90 20:36:03 GMT
References: <561@oglvee.UUCP> <13317@smoke.BRL.MIL> <563@oglvee.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 21

In article <563@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>Fascinating.  I don't think we're seeing this behavior, ...

I'm not sure you understood what I was describing.  You would only see
that when fork()s started to fail, and that normally occurs only when
the user reaches his process-count limit, which is a system
configuration parameter.  The reason this occurred in the operational
demo that I described is that the vendor chose to set up all accounts
being used for the test with the same UID, thereby virtually assuring
that the process limit would be encountered.  Normal use of UNIX does
not have everybody operating under the same UID.

>Does csh under V.4 have the exponential backoff?  I presume under BSD no
>such thing is needed.

It has nothing to do with "BSD vs. SysV".  Any system with a bound on
the number of processes permitted for a given user would encounter
fork() failures (which could of course also occur if the system ran
out of space resources).  I hope my example made it clear why
exponential backoff was a poor strategy.  However, most shells should
attempt to recover from fork() failures to a reasonable degree.