[ On Sunday, December 8, 2002 at 12:09:05 (+0100), Jaromir Dolecek wrote: ]
> Subject: Re: CVS commit: syssrc/sys/kern
>
> It's perfecetly legit for fork() to block until the child can be
> forked. The EAGAIN thing is optional. SUSv3 says:

I don't believe that's a valid interpretation of the standard, nor of
the way it should be implemented in a unix-like system.

First off it is very important to note clearly that you qoted only from
the rationale, not form the standard.  The standard says only this about
the return value of fork():

    RETURN VALUE

     Upon successful completion, fork() shall return 0 to the child
     process and shall return the process ID of the child process to the
     parent process.  Both processes shall continue to execute from the
     fork() function.  Otherwise, -1 shall be returned to the parent
     process, no child process shall be created, and errno shall be set
     to indicate the error.

    ERRORS

     The fork() function shall fail if:

     [EAGAIN]
             The system lacked the necessary resources to create another
             process, or the system-imposed limit on the total number of
             processes under execution system-wide or by a single user
             {CHILD_MAX} would be exceeded.

     The fork() function may fail if:

     [ENOMEM]
             Insufficient storage space is available.


While this doesn't define what "completion" means, and whether there can
be any delay before the parent returns, the general interpretation for
UNIX-like implementations of this standard MUST be that the parent
process not block unduely regardless of whether there's an error or not.
It must return to userland as soon as it's next scheduled to run.  (Yes
that's still necessarily fuzzy to accomodate single-CPU systems.)


> """
> The [EAGAIN] error exists to warn applications that such a condition
> might occur. Whether it occurs or not is not in any practical sense
> under the control of the application because the condition is
> usually a consequence of the user's use of the system, not of the
> application's code. Thus, no application can or should rely upon
> its occurrence under any circumstances, nor should the exact
> semantics of what concept of "user" is used be of concern to the
> application writer. Validation writers should be cognizant of this
> limitation.
> """

This part of the rationale does not say anything about whether a delay
may or may not occur before the parent returns with an error indication.
All it says is that the application cannot portably interpret the
meaning of the error, and that there might not even be such an error.
It definitely does not say that the error might only be returned after
some delay and thus is not really any validation of your argument.

Traditional unix system-call behaviour does not allow for any artificial
delay, no matter what any standard says or does not say.

Note that SuSv3 also says in the rationale section:

     The [ENOMEM] error value is reserved for those implementations that
     detect and distinguish such a condition.  This condition occurs
     when an implementation detects that there is not enough memory to
     create the process.  This is intended to be returned when [EAGAIN]
     is inappropriate because there can never be enough memory (either
     primary or secondary storage) to perform the operation.  Since
     fork() duplicates an existing process, this must be a condition
     where there is sufficient memory for one such process, but not for
     two.  Many historical implementations actually return [ENOMEM] due
     to temporary lack of memory, a case that is not generally distinct
     from [EAGAIN] from the perspective of a conforming application.

This is really what the paragraph that you quoted above refers to.


> My opinion is  that if you frequently bump into your limits during
> normal operation, the system is not configured properly.

Then your opinion is (still) wrong.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>