Path: utzoo!utgpu!watserv1!watmath!att!cbnewsl!sar0
From: sar0@cbnewsl.att.com (stephen.a.rago)
Newsgroups: comp.unix.wizards
Subject: Re: Sys V fork IS broken!
Message-ID: <1990Aug2.034235.28937@cbnewsl.att.com>
Date: 2 Aug 90 03:42:35 GMT
References: <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP> <1990Jul28.195032.18746@watdragon.waterloo.edu>
Organization: AT&T Bell Laboratories
Lines: 49

In article <1990Jul28.195032.18746@watdragon.waterloo.edu>, tbray@watsol.waterloo.edu (Tim Bray) writes:
> 
> Every application I've written, and every other one I've seen (aside from
> amateurish toys that don't check return codes) forks about like this:
> 
>   if ((child = fork()) == -1)
>     FatalSystemError("Serious system trouble! Can't create process!");
>   else if (child == 0)
>   { /* child */ }
>   else
>   { /* parent */ }
> 
> I think this is right and Doug Gwyn's comment is (unusually for him) wrong.  

Sorry, but your code is wrong if you want it to be robust.  Otherwise,
for the typical "I-don't-care" application, it's fine.
For example, the shell will try an exponential backoff if fork fails.

> Having write(2) fail because a disk is full is OK - there are several
> strategies which a program might reasonably adopt to handle this.  But having
> fork() fail because of a likely-transient OS state is a stinking crock.  If
> there is a good chance that the kernel can fix this up without a gratuitous
> time delay, it should do so.  If not (i.e.  process creation has become
> impossible) the whole system is seriously sick and all the applications should
> ideally hear about this PDQ so they can start taking disaster relief
> measures.

If the kernel can't allocate enough memory for a process to fork, then
your system will be in worse trouble than you think.  Especially in SVR4,
where most data structures are dynamically allocated, this is a situation
that requires immediate attention.  It depicts either a memory leak or a
workload that requires more physical memory than available.  Imagine not
being able to log in as root on the console because the system can't
allocate a streams message.

> I don't really think there's a middle ground here.  And speaking
> from my experience in the application community, I think describing absence of
> special-purpose backoff & retry code for handling process creation failure by
> the OS as "bugs in application programs" is pretty arrogant and unrealistic.

Welcome to the world of UNIX.  Face it, since fork can fail because all
the proc slots are in use, if you want it to be robust, your applications
will still need to retry regardless of the fact that fork can fail for
lack of memory.  One failure is just as intermittent as the other, as far
as the application is concerned.  In one case, you would be waiting for
memory to be freed, and in the other, for a process to exit.

Steve Rago
sar@attunix.att.com