Proper way to use fork() and wait()

Question

I have just started learning about fork and wait in Linux and came across this paragraph in the wait() manual page notes:

A child that terminates, but has not been waited for becomes a "zombie". The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait to obtain information about the child. As long as a zombie is not removed from the system via a wait, it will consume a slot in the kernel process table, and if this table fills, it will not be possible to create further processes. If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies.

A question that came to mind after reading this:

Isn't the fact that not using wait() causes a resource waste until the parent terminates, a problem that amplifies when the parent process is meant to be a long lived process in the system? Does this means I should always use wait() as soon as possible after using fork?

The main reason for your application to use wait() is to learn about how the child terminated; it should return exit code 0 on success and greater than 0 if something went wrong. If your parent process creates many children during its run time then, indeed, you should also call wait() to avoid wasting system resources; if you fail doing this, sooner or later your process won't be able to create new children and, even worse, the system itself will start working abnormally. — axiac
You shouldn't call it "as soon as possible", you should call it when required. Your primary takeaway from this paragraph should be: If you're in a situation where you don't particularly require the details of how a child terminated (which is what wait() does), you should still do it at some point to free a process slot. — Aakash Jain

P.P P.P · Accepted Answer · 2014-11-28T08:58:47

Isn't the fact that not using wait() will cause a resource waste until the parent will terminate?

When a child process is running, there's no wastage of resource; it's still doing its task. The resource waste that your citation talks about is only when a child dies but it's parent hasn't reaped it yet i.e. not wait()ed on the child process.

a problem that amplifies when the parent process is meant to be a long lived process in the system?

When your application runs for a very longtime and keeps forking children, there's a chance that the system might run out of resources when many child process are still running or the parent process didn't reap the exited children. It's the job of the application process to to optimally manage the resources on the system and reaping the child processes as soon as they might have done.

Does this means I should always use wait() as soon as possible after using fork?

There's no straight "as early" or "as late" kind of answer to this. For example, parent process might want to carry on do something useful when the child is still running rather than waiting (It might be unnecessary to even check periodically if children status with WNOHANG when parent knows the children might have a long tasks to finish). So in this case, waiting as soon as forking a process might not be what you want. In general, parent should call wait() whenever it expects the child(ren) to have completed its task (or wants to know the stauts of children). The responsibility lies with the programmer to code correctly and call wait() at the most appropriate time.

Proper way to use fork() and wait()

1 Answers