Is System V.4 fork reliable?

[Anthony Shipman]

At the risk of getting in out of my depth!

In article <575 at oglvee.UUCP>, jr at oglvee.UUCP (Jim Rosenberg) writes:
> 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.  I fear no one understands it any more.  Dammit, Doug, it's not that I'm

There could be a deadlock between user level processes. Suppose a process has 
used lots of kernel memory eg with file locks, open files, open inodes etc and 
then sleeps on more memory. Then another such process does the same thing. They
could end up deadlocked. Since shortage of kernel memory is a critical thing
and these deadlocked processes have tied up lots of it the problem could
spread.

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.

Of course this principle would have to be applied to every system call. Other
deadlock protection methods over general user processes are probably
inapplicable.


> the availability of a block in the buffer cache.  (Yeah, I know, there is no

The memory for buffers is preallocated at system boot time.

> Meantime, if architects think they can get away with kernel threads without
> full support for it, and us consumers of UNIX point out that by golly they
> didn't really quite get away with it, hey, it's our bucks, we're entitled.
> When I found that V.4, like V.3, uses an asynchronous page-stealing daemon, it
> made me nervous.  I'm still nervous.

And I'm bitten. My SCO UNIX 3.2 machine (appears to) deadlock frequently on 
going virtual (using the swap space for the first time).
-- 
Anthony Shipman                               ACSnet: als at bohra.cpg.oz.au
Computer Power Group
9th Flr, 616 St. Kilda Rd.,
St. Kilda, Melbourne, Australia
D