CSCI 1730                    Programming Project 4A                  Summer 2009

                              Signaling Processes


This program is due by midnight on ****** Sunday, July 5. ******

The goal of part A of Project 4 is to introduce you to signaling processes.
The processes will consist of one orginal process and several descendents.
In part B you will add inter-process communication by pipes and FIFOs.

The original process will be initiated from the command line by calling an
executable file "starter".  On receiving SIGUSR1 or SUGUSR2 for the first
time, the original process will create a child which is executing "child1"
or "child2", respectively.  The original process will block or ignore a second 
SIGUSR1 signal or a second SIGUSR2 signal.  On receiving SIGTERM the original
process will terminate all its descendents, then itself.  All other signals
are to be blocked or ignored to the extent possible.

The child processes will respond to signals in the same way as the original
process, except that no children will be produced by a process at level "depth",
where "depth" has been specified on the command line with "starter".  Also a 
child process will not attempt to terminate any other processes when it 
receives SIGTERM.

Your program should take one or two command line parameters, where the first
is a positive integer "depth".  The second, if present, is to be the name of
a file to open for writing reports to.  If the second parameter is omitted
then all reports are to be written to standard output.

An example command line is "{albany} starter 9 ReportFileName".

Each process reports just after it starts and, if terminated by SIGTERM,
just before it terminates.  Each initial process report should consist of
a single line which identifies its type (original, type 1, or type 2), PID,
PPID, and if a child its depth.  Children of the original process have depth
1, their children all have depth 2, and so on.  Each terminating process 
report should consist of a single line giving its PID and stating that it
is terminating.

Your project submission should include implementation files starter.c, child1.c,
child2.c, a Makefile and a READ_ME file.  Your Makefile should compile the code
files to the executable files starter, child1, and child2 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.

  *Each child process must be created by fork( ) and some form of exec( ),
   and pauses in execution must be implemented by pause( ).  The fork( ) and
   exec( ) system calls are described in Chapter 8 of the UNIX text, and 
   pause( ) is described in Chaper 10.
	
  *Your program must be written in C.
  
  *Design your program so that each process terminates normally unless it
   has received SIGKILL.

  *Test your "starter" program on various depths (legal and illegal) and
   various strings for the output file, including legal and illegal file
   names, names of files which alreday exist, and the name omitted.
   Also test it with extra command line parameters.  
   
  *The program should be robust and include appropriate error checks.  For
   instance, if in the sample commmand above "ReportFileName" 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 does not conform to a meaningful pattern should result in an error
   message followed at once by termination.  That could be too many, too few,
   or first parameter which does not represent a positive integer in standard
   (sign-free) decimal notation.

  *Signal handling should be done using the POSIX reliable signal functions,
   which are discussed in Chapter 10 of the UNIX text starting at Section 10.8.

  *Hint: note that some commands can target all processes with the same 
   process group id as the caller.  The process group id is discussed in 
   Chapter 9 of the UNIX text.

  *DO NOT run your Project 4A 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.

  *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 "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, and (4) correctness
   and usefulness of the READ_ME file and the Makefile.