Is System V.4 fork reliable?

[Keith Gabryelski]

In article <480 at amanue.UUCP> jr at amanue.UUCP (Jim Rosenberg) writes:
>In article <561 at oglvee.UUCP> jr at 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.

Forgive me, I haven't been keeping up with c.u.w.

>>My question is:  Is this *FIXED* in V.4?
>
>Which, alas, no one has answered.  Surely *somebody* reading this
>group can look at the V.4 source and let us know.  To repeat: do any
>kernel routines called as result of a fork issue kmem_alloc() with
>the flag KM_NOSLEEP?  If the answer is yes then it would seem to me
>V.4 will have the same problem as V.3.

When assigning a process id the kernel will try to allocate a proc_t
without sleeping [ie, pass KMEM_NOSLEEP to *alloc()].  If this fails,
fork() will return EAGAIN.

What isn't reasonable about this?  fork() is documented (under SVR4)
to fail returning EAGAIN if:

	The system-imposed limit on the total number of processes
	under execution by a single user would be exceeded.

or

	Total amount of system memory available when reading via raw
	I/O is temporarily insufficient.

Although I don't know of any other unix varient that documents the
latter case (save SVR3), EAGAIN is a totally reasonable thing to check
for as a return error code from fork().

Pax, Keith