The Programming Interface - Operating Systems: Principles and Practice - page 113

Kernel handles and garbage collection

As we discussed in the previous chapter, when a UNIX process finishes, it calls the
system call exit . Exit can release various resources associated with the process, such
as the user stack, heap, and code segments. It must be careful, however, in how it
garbage collects the process control block (PCB). Even though the child process has
finished, if it deletes the PCB, then the parent process will be left with a dangling pointer
if later on it calls UNIX wait . Of course, we don't know for sure if the parent will ever
call wait , so to be safe, the PCB can only be reclaimed when both the parent and the
child have finished or crashed.
Generalizing, both Windows and UNIX have various system calls that return a handle
to some kernel object; these handles are used in later calls as an ID. The process ID
returned by UNIX fork is used in later calls to UNIX wait ; we'll see below that UNIX
open returns a file descriptor that is used in other system calls. It is important to realize
that these handles are not pointers to kernel data structures; otherwise, an erroneous
user program could cause havoc in the kernel by making system calls with fake handles.
Rather, they are specific to the process and checked for validity on each use.
Further, in both Windows and UNIX, handles are reference counted. Whenever the
kernel returns a handle, it bumps a reference counter, and whenever the process re-
leases a handle (or exits) the reference counter is decremented. UNIX fork sets the
process ID reference count to two, one for the parent and one for the child. The under-
lying data structure, the PCB, is reclaimed only when the reference count goes to zero,
that is, when both the parent and child terminate.

UNIX has a system call, naturally enough called wait , that pauses the parent
until the child finishes, crashes, or is terminated. Since the parent could have
created many child processes, wait is parameterized with the process ID of the
child. With wait , a shell can create a new process to perform some step of its
instructions, and then pause for that step to complete before proceeding to the
next step. It would be hard to build a usable shell without wait .
However, the call to wait is optional in UNIX. For example, the Chrome
browser does not need to wait for its forked clones to finish. Likewise, most
UNIX shells have an option to run operations in the background, signified by
appending an `&' to the command line. (As with fork , the word wait is now
a bit ambiguous. It is used for pausing the current UNIX process to wait
for another process to complete; it is also used in thread synchronization, for
waiting on a condition variable. To disambiguate, we will always use the term
\UNIX wait" to refer to UNIX's wait system call. Oddly, waiting for a thread to
complete is called \thread join", even though it is most analogous to UNIX wait.
Windows is simpler, with a single function called \WaitForSingleObject" that
can wait for process completion, thread completion, or on a condition variable.)

Finally, as we outlined in the previous chapter, UNIX provides a facility for
one process to send another an instant notification, or upcall. In UNIX, the