Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!natinst!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <18491@rpp386.cactus.org>
Date: 8 Aug 90 04:01:27 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <575@oglvee.UUCP> <553@bohra.cpg.oz>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 19
X-Clever-Slogan: Recycle or Die.

In article <553@bohra.cpg.oz> als@bohra.cpg.oz (Anthony Shipman) writes:
>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.

I'm quite pleased to state the AIX V3.1 does not have this same problem
which AT&T has decided to introduce.  Not only does their fork() not fail
for transient shortages of real memory, but it has the added complexity
of working in an environment where almost all system calls are pre-emptable,
and frequently =are= pre-empted, page faulted, put to sleep, and a half
dozen other evils.

For more information on the implementation of the AIX kernel, please see
"Enhancements to the AIX Kernel for Support of Real-Time Applications",
by Kathy A. Bohrer and John T. O'Quin, IBM publication SA23-2619.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org