Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: Sys V fork IS broken!
Message-ID: <13447@smoke.BRL.MIL>
Date: 29 Jul 90 01:48:08 GMT
References: <573@oglvee.UUCP> <13435@smoke.BRL.MIL> <1990Jul28.195032.18746@watdragon.waterloo.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <1990Jul28.195032.18746@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes:
>  if ((child = fork()) == -1)
>    FatalSystemError("Serious system trouble! Can't create process!");
>... 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.

The bug is that your application makes no attempt to recover from a known
class of error, EAGAIN in this case.  I would say the same thing about a
wait() loop that did not properly handle EINTR error returns.  (I bet you
have those, too.)  And of course many applications that directly use the
write() system call do not properly handle short write counts.  None of
these should be considered failings of the kernel; as Terry pointed out
in another recent posting, it is the responsibility of the application to
determine the policy to be used to deal with such situations, and the
best choice for the policy depends very much upon the application.  If
the programmer has not thought about these matters, then he has done an
imperfect job of program design.  Producing high-quality applications is
hard enough as it is; if the kernel were to impose somebody's arbitrary
notion of policy in such cases it would be impossible.