CSCI 1730                    Programming Project 4B                  Summer 2009

                                Pipes and FIFOs


This program is due by midnight on ##### Wednesday, July 8. #####

The goal of part B of Project 4 is to introduce you to pipes and FIFOs by
incorporating them into the processes created for part A.  Here we only
describe the aspects of "starter", "child1", and "child2" which differ 
from those of part A.  In addition there will be a new process, "reader".

The "starter" program should again take one or two command line parameters,
where as before the first is a positive integer "depth".  But the second, if
present, is to be the name of a FIFO to open for writing reports to.  In this
case "reader" will read the reports from the specified FIFO and produce a 
single summary of data from the processes which descended from "starter".
If the second parameter is omitted a pipe is created for transmitting the
reports to "starter", which then compiles a summary and writes it to standard
output.

An example command line of the first sort is "{albany} starter 9 FIFO_Name".
An example command line of the second sort is "{albany} starter 9".
An example command line for "reader" is "{albany} reader FIFO_Name oFile".

Each child process reports only if terminated by SIGTERM, just before it
terminates.  The report just needs to specify whether the process is 
type 1 or type 2, and its depth.  Children of the starter process have depth
1, their children all have depth 2, and so on.

The summary produced by "reader" or "starter" should list, line by line,
for each depth attained the number of processes of each child type.

Your project submission should include implementation files starter.c, child1.c,
child2.c, reader.c, a Makefile and a READ_ME file.  Your Makefile should
compile the code files to the executable files starter, child1, child2, and
reader using gcc.

The notes for part A all apply.  Some additional things to note for part B :

  *The program should be robust and include appropriate error checks.  For
   instance, if in the sample commmand "{albany} starter 9 FIFO_Name".
   there is already an existing file (of any type) named "FIFO_Name"
   then an error message should be issued; if it does exist already, it
   should not be removed or altered.  If such a file does not exist already
   then it should be created as a FIFO and opened for writing, with error
   messages if creation or opening can't be performed.
   
  *In the sample command "{albany} reader FIFO_Name oFile", an error message 
   should be issued if "FIFO_Name" is not an already exisiting FIFO, or if it
   can't be opened for reading.  Error messages should result if the number
   of command line parameters for "reader" is not 2, or if "ofile" already
   exists, or if it can't be created and opened for writing.  If "ofile" does
   already exist it should not be removed or altered.