Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: Who is responsible for a retry
Message-ID: <18485@rpp386.cactus.org>
Date: 3 Aug 90 06:35:49 GMT
References: <866@mwtech.UUCP> <1809@necisa.ho.necisa.oz> <18479@rpp386.cactus.org> <13468@smoke.BRL.MIL>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 20
X-Clever-Slogan: Recycle or Die.

In article <13468@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>Actually, there have been several different implementations of fork(),
>all of which have been able to fail for reasons of a transient shortage
>of resources.  The details are the only thing that have varied..

I've been spared the gory details of System V fork() most of my adult
life, but in my childhood (last week when this started) I did check
V6 and V7, and sure enough - neither of those fail for lack of
anything short of swap space.  Now, I have V.2 source laying around
work someplace, I'd be happy to look and see what fork() does in
the case of no physical memory there.  But my recollection is, it
doesn't fail for transient shortages of physical memory.

Anyone with a fork() older than V.3 which fails for transient
shortages of memory is free to send me the sordid details.  That way
I can start a list of which UNIX products not to purchase.  Obviously
the disease starts about V.3.2 or so and I'd rather avoid the plague.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org