Path: utzoo!utgpu!watserv1!watmath!att!cbnewsl!sar0
From: sar0@cbnewsl.att.com (stephen.a.rago)
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <1990Aug4.011958.5416@cbnewsl.att.com>
Date: 4 Aug 90 01:19:58 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <575@oglvee.UUCP>
Organization: AT&T Bell Laboratories
Lines: 21

In article <575@oglvee.UUCP>, jr@oglvee.UUCP (Jim Rosenberg) writes:

[much rambling deleted...]

> I am truly mortified that **NO ONE** has posted an explanation of just what
> the deadlock would be if the kernel did allow sleep in allocating memory for a
> fork.

There is a deadlock if the kernel had to wait for proc slots, because if
all the processes were trying to fork, and nobody intended to exit, then
every process (except the kernel procs and init) would be waiting indefinitely
in the kernel for an event that would never occur.

However, the same deadlock is still possible when you kmem_alloc(KM_SLEEP)
a proc structure, only it's a lot less likely to occur because the memory
can be coming from other places (like STREAMS messages, etc.)  The only
time you'll deadlock is when no more memory is available and everyone is
waiting to allocate the space for their own proc structure.

Steve Rago
sar@attunix.att.com