The purpose of this lab is to gain familiarity with UNIX process management and interprocess communication using pipes.
The assignment has two parts, and it is recommended that it be accomplished in two corresponding phases. Two lab periods are allocated for this project.
Design and implement a UNIX C++ application that accepts a command line of the form:
lab2 <infile> <outfile> <time> <cmd> <args ...>
For example:
lab2 a.txt junk.txt 10 ls -l abc.c def.*
The application should create three child processes. Note that the program you write should only have one executable image, in spite of the fact that there will be multiple processes running at the same time.
Child process 1. The first child process should copy the text file <infile> to <outfile>, a line at a time. As each line is copied, modify it as follows:
Note: you may wish to perform these two operations separately; see part 2 below.
Insert a delay (e.g., sleep system call) after copying each line or group of lines so that this process does not complete too quickly. If <infile> cannot be opened, or <outfile> already exists, this process should exit with a "not successful" status.
Child process 2. The second child process should run for <time> seconds, and then exit with normal status. During the "run" interval, this process should compute the square root of successive integers (i.e., 1.0, 2.0, 3.0, ...); before exiting, this process should write the largest integer and square root values to a file. (Note that only the largest integer and its square root should be written to the file.) For timing, use the alarm system call with a signal handler (hint: in the signal handler, set a global flag that is tested on each iteration of the "square root" loop).
Child process 3. The third child process should exec the command (<cmd>), using the rest of the arguments on the original command line (<args ...>). Note that there may be any number of arguments (including zero) following <cmd>.
Main application process. The main application should print a message when each of the child processes exits. This message should indicate how the child terminated (normal or signal, exit status or signal number). The messages should appear as soon as each process exits; the termination order may vary. When all children have terminated, the main application should print a final message and then exit itself.
While the application is running, observe the processes with the ps command, perhaps from another terminal window. The -t option to ps can be used to limit the output to processes associated with a particular terminal. You might try using the kill command to send a SIGALRM (note spelling!) signal to the "square root timer" process while it is running.
Modify the above application so that the file copying is actually done by two processes connected by a pipe:
See the man page for pipe. Since the pipe file descriptors are designed for low-level (i.e., read/write) I/O, you will probably have to use the ifstream and ofstream constructors that create an I/O stream from a file descriptor. These overloaded constructors are not part of the ANSI/ISO C++ standard, but are often provided on UNIX systems.
Remember to close the end of the pipe that each process is not using. Reading from the pipe will only signal "end of file" when the last writer closes it, so you want each process to have only one end open.
The primary components of grading for this project are:
Prepare a text file containing a brief report (one report per group) detailing any problems you encountered and any questions that remain about the lab material. Each section of code (source file or portion thereof) should be reviewed by a team member other than the author, and should be clearly labeled with the names of the author(s) and reviewer(s). Create a compressed tar archive file (named "lab2_xx.tar.Z", where "xx" is your team number) containing the report, source (part 2 only), and make files (no object or executable files) from this lab. Attach this file to a mail message, and send it to sebern@msoe.edu. Do not discard your original files, in case anything gets lost in the email system.
The report is due two hours before lab of week 4.
This page was last updated on November 29, 1998; send comments to Mark Sebern.