April 12, 2006

Coverage: [USP] Chapter 11

Back to Signal Handling in the Foreground

William Kimball asks `why not just remove the if statement entirely from the child?'
- because the exec will not unblock by default
why is wait now at the top of the loop?
how to integrate with pipelines and background processes?

a process group is a collection of processes
- established so a group of processes can receive a signal as a unit
process group id: associated with each process
use negative sign with kill
the process id of process group leader is equal in value to the id of the process group
group persists as long as some process is in it
- thus, a group may be without a leader
child processes inherit the group id of their parent
setpgid: allows a process to change its group
- id of calling process assumed if passed a 0 for pid
- the process with pid becomes the leader if passed a 0 for gpid
- parent can use this function to change the group of its child before a call to exec
- a child can establish a new group for itself by calling this function with pgid set to the value of its pid
getpgrp returns the process group id of the caller

a session is a collection of process groups
- established for purposes of job control
- creator is called the session leader
  - the shell is a session leader
- session identified by the process id of its leader
every process belongs to a session, inherited from its parent
getsid: returns the group id of the session leader of the process specified by pid
setsid: creates a new session and makes the caller its leader
- also creates a new group with id equal to the value of the caller's process id
- results in one session of one group of one process, with no controlling terminal
Example 11.24:
(all background process groups)
```
ls -l | sort -n + 4 | grep testfile > testfile.out &
grep process | sort > process.out &
du . > du.out &
cat /etc/passwd | grep users | sort | head > users.out &
```
- all processes will have the same session id (the process id and session id of the shell)
- one process (i.e., the leader) in each group will have the same id as the group

a session may have a controlling terminal associated with it
shell uses the controlling terminal to interact with user
a controlling terminal is associated with only one session
while session may contain multiple groups, only one at a time can perform I/O through the controlling terminal
- called the foreground process group or foreground job
- others are called the background process groups or background jobs
  - processes in this group are not affected by keyboard input from the terminal controlling the session to which it belongs
main purpose of job control is to shift processes between these two groups
ctermid: used to obtain the name of the caller's controlling terminal
Example 11.22: <ctrl-c> during execution of ls -l | sort -n +4 | more
- all 4 processes belong to the foreground process group
Example 11.23: <ctrl-c> during execution of ls -l | sort -n +4 | more &

shell does not wait for a background process
background process is not killed by a SIGINT from the keyboard
rusers & is a long running command which is good for purposes of testing background processes
ush5.c handles background processes
- must determine if an & is present on the command line before forking
  - because both parent and child need this information
- parent does not wait
- child calls setpgid to detach itself from the foreground process group of its session
demonstration of zombies
ush6.c address the problem of zombie processes
- fork twice thus creating a child and grandchild
- child exits immediately
- this leaves the grandchild as an orphan adopted by init
- now have parent wait for all children, even background processes
new problem: shell must be able to detect of background process was stopped due to a SIGSTOP
- waitpid has an option for detecting children stopped by signals
- however, due to the extra fork, the command is run as a grandchild of the shell, not a child
- solution: don't use extra call to fork; call waitpid with WNOHANG
  - more direct solution approach
  - implemented in ush7.c

a shell has job control if it provides support for moving processes from the foreground to the background and vice versa
concurrent execution
- commands which allow control over multiple processes which are executing concurrently
- foreground: the current process which is attached to the user's terminal
- background: processes executing without being attached to a terminal (batch commands)
- command &: any shell command can be followed by an & (before the return) to run the command in the background

[1]  + Stopped             spell termpaper
[2]  - Running             find /usr -name main.exe -print &

$ fg %<number>: moves a running or stopped background job to the foreground
$ <ctrl-z>: suspends the current job and moves it to the background in the stopped state in one stroke
$ bg %<number>: resumes execution of a stopped job in the background.
combo of <ctrl-z> bg makes a foreground job a running background job
$ kill -STOP %<number>: suspends a running background job
$ kill %<number>: terminates the process with the corresponding job number

UNIX Systems Programming: Concurrency, Communication, and Threads