Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rutgers!cbmvax!ag
From: ag@cbmvax.commodore.com (Keith Gabryelski)
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <13426@cbmvax.commodore.com>
Date: 25 Jul 90 16:50:59 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP>
Reply-To: ag@cbmvax (Keith Gabryelski)
Organization: Commodore-Amiga Unix; West Chester, PA
Lines: 38

In article <480@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) 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.

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