In this lab, you will learn the following topics and practice C programming skills.

1. Using signal handlers, signal() and sigaction()
2. Scheduling alarm signals with alarm()
3. Using siginfo_t when handling SIGCHLD

Run the following command

~aviv/bin/ic221-up

Change into the lab directory

cd ~/ic221/labs/10

All the material you need to complete the lab can be found in the lab directory. All material you will submit, you should place within the lab directory. Throughout this lab, we refer to the lab directory, which you should interpret as the above path.

For this lab, all ubmission should be placed in the following folder:

~/ic221/labs/10

You are not required to provide your own Makefiles for this lab.

In the top level of the lab directory, you will find a README file. You must fill out the README file with your name and alpha. Please include a short summary of each of the tasks and any other information you want to provide to the instructor.

You are provided a test script which prints pass/fail information for a set of tests for your programs. Note that passing all the tests does not mean you will receive a perfect score: other tests will be performed on your submission. To run the test script, execute test.sh from the lab directory.

./test.sh

You can comment out individual tests while working on different parts of the lab. Open up the test script and place comments at the bottom where appropriate.

Parents can wait() on children to terminate, or for any other kind of state change. This includes process that are stopped or continued. Unfortunately, the basic wait() system call won't cut it, and instead, we need to use the waitpid() system call, a slight more advanced form of wait().

Here is an example of how waitpid() is used in the fg-shell program:

if ( (pid = waitpid(-1, &status, WUNTRACED)) < 0){
  perror("wait failed");
  _exit(2);
}

The first argument, -1, indicates to wait for all children. Like before, the status is written to status, and the option WUNTRACED says to also return when children are either stopped or continued.

You can test why a child process changed state, that is, why a SIGCHLD was delivered using the following macro:

WIFSTOPPED(status);

which returns true when waitpid() returned because a child was stopped. And similarly, there is a macro to test when a child is continued:

WIFCONTINUED(status);

These may come in handy when managing children.

One thing you must do when you have processes running in the foreground other than the shell is tell the terminal device driver to which process (or group of processes) to deliver terminal signals, such as those generated from Ctrl-C and Ctrl-Z.

For example, if we are running a process in the foreground and we want terminate the process with Ctrl-C, we don't want the foreground process and the shell to terminate due to delivering the SIGINT signal. To ensure this doesn't happen, we need to inform the terminal device driver which process is in the foreground, and then only the right process will receive the signal.

The system call that does this is tcsetpgrp(). The "tc" stands for "terminal control." The function takes two options, a file descriptor for the terminal tty, which is usually 0 for standard input, and a pid for the foreground process group.

int tcsetpgrp(int fd, pid_t pgrp);

The return value os positive if succesful and negative on error. Use perror() to report erros.

Transferring control the terminal should solely be the domain of the shell. The child should never call tcsetpgrp(). The shell will call tcsetpgrp() in the following situations

• When control of terminal is going from the shell to the child process, i.e., the child is becoming the foreground process.
• When control of the terminal is going from the child process to the shell, i.e., the shell is becoming the foreground process.

There is one more property of =tcsetpgrp() that you must control for. Looking at the main page closely, the following information is provided:

If tcsetpgrp() is called by a member of a background process group in its session, and the calling process is not blocking or ignoring SIGTTOU, a SIGTTOU signal is sent to all members of this background process group. #+END_EXAMPLE

If you consider the situation above where terminal control is transferring from the child to the shell, the shell will need to call tcsetpgrp() to itself. However, the shell is no longer in the foreground process group, the child is since it was terminating. As a result, the shell will be sent a SIGTTOU signal whose default action is to stop. This will cause your shell to hang.

To prevent these situations, you need to make sure the shell is blocking/ignoring SIGTTOU:

signal(SIGTTOU, SIG_IGN);

To continue a process that was previously stopped, you must send that process a signal that says, "hey, you, wake up and continue what you were doing." The signal that does that is SIGCONT, and you can deliver that signal using the kill() system call.

We'll discuss kill() in more detail when covering inter-process communication, but for this lab, you'll exclusively use it to continue a stopped process allowing it to run in the foreground. Here is an example usage:

kill(last_pid, SIGCONT);

Here, last_pid, refers to the child process pid that was most recently stopped with Ctrl-z.