Who is responsible for a retry (was Re: Is System V.4 fork reliable?)

[terryl at sail.LABS.TEK.COM]

In article <866 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>In article <7885 at tekgvs.LABS.TEK.COM> terryl at sail.LABS.TEK.COM writes:
>[many wise words about KISS principle and the spirit of unix deleted]
>
>But IMHO it's not quite appropriate here. I think the questions here is:
>
>		Who should retry if a fork fails? 

     Well, I'll agree to disagree!!! (-: IMHO, the KISS principle and the
spirit of unix IS appropriate here, and you deleted one of my main reasons
why with respect to your question "Who should retry if a fork fails?"

     And the reason is one of policy; as I said in my previous post, the
kernel SHOULD NOT be making policy decisions that are better left to the
application program. Having the kernel ALWAYS sleeping and retrying if a
fork() fails is a policy decision that may not always be appropriate.

     However, many people have brought up a point that I didn't think about
at first; the error code EAGAIN is overloaded to mean two totally different
things: one, a transient condition of not enough system resources(i.e. disk
swap space, real memory, etc.) to satisfy the request, and two, a more perma-
nent condition of running into some system-wide limits (i.e. no more process
slots, too many processes for this user id, etc.), and I'll be happy to agree
(-: on this point that the two error conditions should be signaled differently.


			Terry Laskodi
			     of
			Tektronix