Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Who is responsible for a retry (was Re: Is System V.4 fork reliable?)
Message-ID: <1820@necisa.ho.necisa.oz>
Date: 8 Aug 90 00:57:49 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> <35@kings.co.uk>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 26

In article <35@kings.co.uk> lls@kings.UUCP (Superuser) writes:
>
>The code that I write does check for EAGAIN and retry - however, other
>utilities and packages that I call (including /bin/sh) do not - how do 
>I fix that?

I've just read the the System V.2.2 shell code and guess what?
It retries the fork() with backoff.  So your shell must be broken.

The deal is that when fork() fails -- all is not well.  The kernel is
not psychic and can't predict what will happen in the future.  The
caller of fork() is responsible to take action.

When fork() does fail what can you do?  Not much, you can give up
in disgust or retry.  BUT THERE IS NO GUARANTEE THAT THE ANY AMOUNT
OF RETRYING WILL GET YOU THAT NEW PROCESS.  What's happened is that a
kernel resource has been exhausted and you have no way of predicting
whether any relevant resources in use will be freed up in the future.

I'm with presotto & hume.  But when you're faced with retrying you have
to ask the question -- is it worth it, and if so how long should I try?


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''