    tt(Monitor)'s core activities are performed by tt(run). It
performs the following tasks:
    itemization(
    it() Initially, the tt(Monitor) object only monitors its standard
input. The set of input file descriptors to which tt(d_selector) listens
is initialized to tt(STDIN_FILENO).
    it() Then, in a loop  tt(d_selector)'s tt(wait) function is called.
If input on tt(cin) is available, it is processed by tt(processInput).
Otherwise, the input has arrived from a child process. Information sent by
children is processed by tt(processChild).
    it() To prevent emi(zombie)em(s), the child processes must catch em(their)
children's termination signals. This is discussed below.

As noted by Ben Simons (tt(ben at mrxfx dot com)) tt(Monitor) must not catch
the termination signals.  Instead, the process spawning child processes has
that responsibility (the underlying principle being that a parent process is
responsible for its child processes; a child process, in turn, is responsible
for its own child processes).
    it() As stated, tt(run)'s source file also defines and initializes
tt(s_initialize) to ensure the proper initialization of the tt(s_handler)
array.
    )
    Here is tt(run)'s implementation and tt(s_initialize)'s definition:
        verbinclude(-a examples/monitor/run.cc)

    The member function tt(processInput) reads the commands entered by the
user using the program's standard input stream. The member itself is rather
simple. It calls tt(next) to obtain the next command entered by the user, and
then calls the corresponding function using the matching element of the
tt(s_handler[]) array. Here are the members tt(processInput) and tt(next):
        verbinclude(//INPUT examples/monitor/processinput.cc)
        verbinclude(//NEXT examples/monitor/processinput.cc)

    All other input sensed by tt(d_select) is created by child
processes. Because tt(d_select)'s tt(readFd) member returns the corresponding
input file descriptor, this descriptor can be passed to
tt(processChild). Using a ti(IFdStreambuf) (see section ref(IFDBUF)), its
information is read from an input stream. The communication protocol used here
is rather basic. For every line of input sent to a child, the child replies by
sending back exactly one line of text. This line is then read by
tt(processChild):
        verbinclude(//CHILD examples/monitor/processchild.cc)
    The construction tt(d_child[fd]->pid()) used in the above source deserves
some special attention. tt(Monitor) defines the data member tt(map<int,
shared_ptr<Child>> d_child).  This map contains the child's order number
as its key, and a (shared) pointer to the tt(Child) object as its value. A
shared pointer is used here, rather than a tt(Child) object, since we want to
use the facilities offered by the map, but don't want to copy a tt(Child)
object time and again.
