Suppose a parent process performs the following steps:

/* Call fork() to create a number of child processes, each of which
   remains in same process group as the parent */

/* Sometime later... */
signal(SIGUSR1, SIG_IGN);     /* Parent makes itself immune to SIGUSR1 */

killpg(getpgrp(), SIGUSR1);   /* Send signal to children created earlier */

What problem might be encountered with this application design? (Consider shell pipelines.) How could this problem be avoided?

Write a program to verify that a parent process can change the process group ID of one of its children before the child performs an exec(), but not afterward.

Write a program to verify that a call to setsid() from a process group leader fails.

Modify the program in Example 34-4 (disc_SIGHUP.c) to verify that, if the controlling process doesn’t terminate as a consequence of receiving SIGHUP, then the kernel doesn’t send SIGHUP to the members of the foreground process.

Suppose that, in the signal handler of Example 34-6, the code that unblocks the SIGTSTP signal was moved to the start of the handler. What potential race condition does this create?

Write a program to verify that when a process in an orphaned process group attempts to read() from the controlling terminal, the read() fails with the error EIO.

Write a program to verify that if one of the signals SIGTTIN, SIGTTOU, or SIGTSTP is sent to a member of an orphaned process group, then the signal is discarded (i.e., has no effect) if it would stop the process (i.e., the disposition is SIG_DFL), but is delivered if a handler is installed for the signal.