CSCI 1730                    Programming Project 3B                  Summer 2009

                                 Process Tree


This program is due by midnight on Sunday, June 28.

The goal of part B of Project 3 is to introduce you to the use of wait( ) and
waitpid( ) in process control by incorporating them into part A of Project 3.
There will be two new features in part B:
 * parameters depth and arity will be specified on the command line, and each
   process will fork( ) exactly arity children down to the level given by 
   depth;
 * wait( ) or waitpid( ), rather than sleep( ), will be used to to attempt to
   enforce the reporting order indicated by the -c or -p flag.
  
Your program should take four command line parameters, where the first
is the name of a file to open for writing its reports to.  The second and
third will supply the depth and arity, respecively.  The fourth parameter
is a flag to indicate whether, for each parent-child pair of processes, the
parent should report first (-p) or the child should report first (-c).

An example command line is 

            {albany} ptree ofile 3 2 -c

where "ptree" is the name of your executable file.  Use wait( ) or waitpid( )
to attempt to manage that each child should report before its parent.  In
this example 15 processes will be created and reported in ofile, since there
will be 1 at level 0 (the original ptree process), 2 at level 1, 4 at level 2,
and 8 at level 3.

Each report should state the PID and then the PPID, in a single line.

Your project submission should include an implementation file ptree.c,
a Makefile, a READ_ME file, and a REPORT (see below).  Your Makefile
should compile ptree.c to the executable file ptree using gcc.

Some things to note:

  *The names of the files submitted and of the executable file generated
   by the Makefile must be followed exactly, so that the teaching assistant
   and the instructor can test your project without editing your code.

  *Child processes must be created by fork( ), and  sleep( ) should not be
   used at all.
	
  *Your program must be written in C.
  
  *All file I/O must be done using the standard I/O library, which is
   described in chapter 5 of the UNIX text.

  *Design your program so that each process terminates normally.

  *Test your "ptree" program on various strings for "ofile", including
   legal and illegal file names, and names of files which alreday exist.
   Also test your "ptree" program on various values of depth and arity,
   and both flags.

  *However, do NOT run your Project 3B code while logged onto "odin".
   Instead, do your testing on one of the Linux workstations in the 307 lab.
   For remote access you can log onto one of those workstations via ssh to
   128.192.251.[15-34].  They have exactly the same file system, software, etc.
   as "odin", and in fact the project grading will be done one on of the
   workstations too.  Once you log on, execute "w" to see if someone else
   is already using that workstation.  Find one that nobody else is using at
   the time.
   
  *For testing purposes keep arity^depth within 100 or so, since this is
   roughly the number of processes you'll create.  Note whether the -c and
   -p flags work as expected.  Your REPORT file should contain a description
   of any problems with the behavior of "ptree" with the -c or -p flag, how
   these problems relate to the values of "depth" and "arity", and what you
   think the likely reason(s) are for those problems.
  
  *The program should be robust and include appropriate error checks.  For
   instance, if in the sample commmand above "ofile" already exists
   then an error message should be issued; if it does exist already, it
   should not be removed or altered.  Any sequence of command line parameters
   which is not meaningful should result in an error message followed at once
   by termination.  That could be too many parameters, too few, "depth" or
   "arity" not nonnegative integers, or a fourth parameter which is not
   "-c" or "-p".

  *The submission procedure and requirements common to all projects are
   described on a separate page which is linked from the course "projects"
   sub-page.  Follow the submission procedure carefully.  Note that for 
   submission (as opposed to testing) you must be logged onto "odin".

  *A project which does not compile on "odin", or on "albany" or one of the
   other Linux workstations in the 307 lab, using gcc for GCC 4.1.2, will score
   0.  Projects which do compile properly will be scored out of 100
   (if on time) based on (1) correctness of operation, (2) quality of design,
   (3) coding style and documentation of the source code, (4) correctness
   and usefulness of the READ_ME file and the Makefile, and (5) quality of
   the REPORT.