Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!bunyip!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <1824@necisa.ho.necisa.oz>
Date: 9 Aug 90 04:08:22 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <575@oglvee.UUCP> <553@bohra.cpg.oz>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 35

In article <553@bohra.cpg.oz> als@bohra.cpg.oz (Anthony Shipman) writes:
>At the risk of getting in out of my depth!
>
> [stuff deleted]
>
>A standard simple "naive" solution to break the deadlock is to kill one of the
>processes at the request point. In this case, make the fork() fail. If several
>retries fail then abort the program (and release memory). An indefinite wait
>would be dangerous.
>

NO, NO, NO!  You do not _understand_.  _Never_ do that.  NEVER!

Which proc will you kill?  And when (if ever) will it run so it can exit()?

It's very simple.  When you're low on ram & swap and processes are
fighting for this resource there's bugger all you can do.  Sure you
can purge a few sticky texts but in a pathological case you run out
of resources and there is nothing you can do.

What is required are pre-emptive measures, such as:

   * memory limits
   * working set limits
   * warn that resources are about to expire (say 90% consumed)

With these things a human can make decisions that will best serve
the system's purpose.  You've only got so much cake so you'd better
choose well how it will best be eaten.  Prevent the disaster from
happening and then you won't have to code in disaster recovery.


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

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