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.