    The member function tt(fork) calls the system function tt(fork)
(Caution: since the system function tt(fork) is called by a member
function having the same name, the tt(::) scope resolution operator must be
used to prevent a recursive call of the member function itself).
The function tt(::fork)'s  return value determines whether tt(parentProcess)
or  tt(childProcess) is called. Maybe redirection is
necessary. tt(Fork::fork)'s implementation calls tt(childRedirections)
just before calling tt(childProcess), and tt(parentRedirections) just
before calling tt(parentProcess):
        verbinclude(-a examples/fork.cc)
    In tt(fork.cc) the class's emi(internal header file) tt(fork.ih) is
included. This header file takes care of the inclusion of the necessary system
header files, as well as the inclusion of tt(fork.h) itself. Its
implementation is:
        verbinclude(-a examples/fork.ih)

    Child processes should not return: once they have completed their tasks,
they should terminate. This happens automatically when the child process
performs a call to a member of the ti(exec...) family, but if the child
itself remains active, then it must make sure that it terminates properly. A
child process normally uses ti(exit) to terminate itself, but note that
tt(exit) prevents the activation of destructors of objects
        hi(destructor: called at exit)
        hi(exit: calling destructors)
    defined at the same or more superficial nesting levels than the level at
which tt(exit) is called. Destructors of globally defined objects em(are)
activated when tt(exit) is used. When using tt(exit) to terminate
tt(childProcess), it should either itself call a support member function
defining all nested objects it needs, or it should define all its objects in a
compound statement (e.g., using a tt(throw) block) calling tt(exit) beyond
the compound statement.

    Parent processes should normally wait for their children to complete.
Terminating child processes inform their parents that they are about to
terminate by sending a emi(signal) that should be caught by their parents.  If
child processes terminate and their parent processes do not catch those
signals then such child processes remain visible as so-called emi(zombie)
processes.

    If parent processes must wait for their children to complete, they may
call the member tt(waitForChild). This member returns the exit status of a
child process to its parent.

    There exists a situation where the em(child) process em(continues) to
live, but the em(parent) dies. This is a fairly natural event: parents tend to
die before their children do. In our context (i.e. bf(C++)), this is called a
emi(daemon) program. In a daemon the parent process dies and the child program
continues to run as a child of the basic ti(init) process. Again, when the
child eventually dies a signal is sent to its `step-parent' ti(init). This
does not create a zombie as tt(init) catches the termination signals of all
its (step-) children.  The construction of a daemon process is very simple,
given the availability of the class tt(Fork) (cf. section ref(DAEMON)).
