Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!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: <18479@rpp386.cactus.org>
Date: 1 Aug 90 04:39:38 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP> <7885@tekgvs.LABS.TEK.COM> <866@mwtech.UUCP> <1809@necisa.ho.necisa.oz>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 29
X-Clever-Slogan: Recycle or Die.

In article <1809@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes:
>When fork() fails with EAGAIN it fails for a good reason.
>
>How many lines of user-mode code does it take to code up retries?
>
>About 20.
>
>It would seem that there is some consensus to change the semantics of
>fork() to retry.  This would break a critical interface.  System calls
>do one thing, and one thing well.

fork() never failed before for lack of kernel memory - the change in
behavior was recently introduced - this is what people are complaining
about.

[ Gross simplification follows ... ]

The previous behavior was allocate memory for the child, and if the
allocation failed, swap the entire image.  But the process image was
left in memory, which had the effect of creating two copies of the
process - one in memory and one on the swapper.

So, even when there was a shortage of kernel memory, the process would
be created, even though it was swapped out.  This isn't some new
function people want - it's the old, pre-V.4 function people want -
you know, the same stuff that's been around since, say, 6th Edition?
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org