[68] in 6.033-lab
Notes on waitpid system call
daemon@ATHENA.MIT.EDU (David Mazieres)
Fri Feb 27 23:21:38 1998
Date: Tue, 24 Feb 1998 18:20:50 -0500 (EST)
From: David Mazieres <dm@reeducation-labor.lcs.mit.edu>
To: 6.033-lab@MIT.EDU
Resent-To: 6.033-lab-mtg@menelaus.MIT.EDU
Resent-From: "Kevin 'Bob' Fu" <fubob@mit.edu>
As I mentioned to people in my recitation, your proxies will be tested
to make sure they don't crash or overload the system when given many
connection requests.
To do this, you must stop calling accept whenever the number of file
descriptors you use in a process is over 56, or whenever you have
spawned more than, say, 50 processes. When a client quits and you
free up file descriptors or processes, you should then start calling
accept again.
If you are writing an asynchronous server with an event-loop, then
this should be relatively straight-forward. The multifinger example
of the TCP handout does exactly this.
If you are spawning processes with fork, this becomes more
complicated. You will need to keep track of how many processes you
have outstanding. Keeping track of the number of processes you create
is easy (how many times did you call fork?), but knowing when
processes exit is a bit trickier.
Unix allows you to poll or wait for a child process with the waitpid
system call. Recall that the child process relation is NOT transitive
in Unix. If process A forks process B, and B forkes C, then C is not
and never will be a child of A, even if B exits. The simplified usage
for waitpid is (see the man page for details):
waitpid (-1, NULL, WNOHANG);
This will return -1 if no child process have exited, or a process ID
of a process that has exited.
waitpid (-1, NULL, 0);
This will return -1 if there are no child processes. Otherwise, it
will wait for a child to exit and return its PID.
