Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!sail!terryl
From: terryl@sail.LABS.TEK.COM
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <7885@tekgvs.LABS.TEK.COM>
Date: 27 Jul 90 18:27:40 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP>
Sender: news@tekgvs.LABS.TEK.COM
Reply-To: terryl@sail.LABS.TEK.COM
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 74

In article <573@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>In <13426@cbmvax.commodore.com> ag@cbmvax.commodore.com (Keith Gabryelski) writes:
>>>In article <561@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>>>>Somewhere along in the development of System V, fork became an
>>>>unreliable system call....
>>Unreliable in what way?  fork() has always been documented to fail
>>if there isn't enough system resources.
>
>*** OPEN DRAGON MOUTH ***
>

     Delete MANY, MANY lines of bitching and moaning about why the "kernel"
should sleep if system resources can't be found for a fork, instead of just
returning an error condition....

>My personal view is that a kernel whose only mutual exclusion mechanisms are
>sleep-wakeup and spl() just makes it too complicated to really fix this and
>allow sleep.  Once upon a time there was a consensus that the kernel needed to
>be rewritten from scratch.  Once upon a time there was the famous V.5 skunk
>works doing exactly this, and based on what Bill Joy told me once it sounds
>like it would have dealt with this kind of problem.  But then the skunk works
>became politically untenable after the OSF rebellion, so now we seem not to
>hear much talk about how important it is to rewrite the kernel.  (Except from
>OSF, CMU, who say they've already done it ... :-))
>
>We only hear talk that it is "reasonable" to bother the application with the
>fact that the system just happens to be kind of busy at the moment, but busy
>with a problem on which it *should* be able to sleep ...


     Well, there's a couple of reasons why "it is reasonable to bother the
application" with the fact that system resources are a little scarce, and could
you try your request again later???? These reasons go WAY BACK (we're talking
ancient history here, boys and girls!!! (-:), and are some of the philosophies
espounded by Ritchie, Thompson, Kernighan, et. al. (hope I spelled their names
right!!! (-:).

     The first is "KISS" (Keep It Simple, Stupid). Don't clutter up the code
with obscure and esoteric algorithms when a simpler one will do; makes the
code easier to maintain, and mucho easier to understand. Unfortunately, with
the sophistication of today's hardware, it is becoming increasingly difficult
to "KISS" (pun intended!!! (-:).

     A direct corollary of "KISS" is thus: It is better to make 20 programs
each do one thing well, than it is to make one program do 20 things. Not only
is it better, it is also easier, and promotes modularity and re-use of compo-
nents. Unfortunately, this concept has long since been abandoned MANY, MANY
moons ago, and I for one am sad to see it go (I submit the options of `cat' and
`ls' as prime examples; I'm sure astute readers can think of their favorite
examples of this...).

     The second reason is thus: for the most part, the "kernel" should NOT
impose policy; it should be up to the individual application to impose it's
policy that it wants. If the "kernel" were to impose policy, it would limit
the application's choices, which Ritchie, et. al. decided "is a bad thing to
do". The "kernel" should be thought of as mainly a "system resource manager",
with just enough policy to make things work. The file system is an excellent
axample of this. As far as the "kernel" is concerned, files are just a sequence
of bytes; the "kernel" makes no assumptions on what these sequences of bytes
really means. It is up to the application to determine what these means (OK,
yes, there are a COUPLE of places where the "kernel" knows a priori what these
bytes mean, e.g. an executable header...).

     So, for Mr. Rosenberg's assertion that "the kernel SHOULD sleep on a
resource shortage", this is imposing a policy upon the application that is
better left to the application.

     BTW, this is all IMHO, etc., and if I've misrepresented Mr. Ritchie's
position, apologies in advance, etc....


			Terry Laskodi
			     of
			Tektronix