job control signals unix:
Of the signals shown in signal concept, POSIX.1 considers six to be
job-control signals:
SIGCHLD
|
Child
process has stopped or terminated.
|
SIGCONT
|
Continue process, if stopped.
|
SIGSTOP
|
Stop signal (can't be caught or ignored).
|
SIGTSTP
|
Interactive
stop signal.
|
SIGTTIN
|
Read
from controlling terminal by member of a background
process
group.
|
SIGTTOU
|
Write
to controlling terminal by member of a background process
group.
|
Except for SIGCHLD, most application programs don't handle these signals: interactive
shells usually do all the work required to handle these signals. When we type
the suspend character (usually Control-Z), SIGTSTP is sent to all
processes in the foreground process group. When we tell the shell to resume a
job in the foreground or background, the shell sends all the processes in the
job the SIGCONT signal. Similarly, if SIGTTIN or SIGTTOU is delivered
to a process, the process is stopped by default, and the job-control shell
recognizes this and notifies us.
An exception is a process that is managing the terminal: the vi(1) editor, for example. It needs to know when the user wants to
suspend it, so that it can restore the terminal's state to the way it was when vi was started. Also, when it resumes in the foreground, the vi editor needs to set the terminal state back to the way it wants it,
and it needs to redraw the terminal screen. We see how a program such as vi handles this in the example that follows.
There are some interactions between the job-control signals. When any
of the four stop signals (SIGTSTP, SIGSTOP, SIGTTIN, or SIGTTOU) is generated for a process, any pending SIGCONT signal for that process is discarded. Similarly, when the SIGCONT signal is generated for a process, any pending stop signals for that
same process are discarded.
Note that the default action for SIGCONT is to continue
the process, if it is stopped; otherwise, the signal is ignored. Normally, we
don't have to do anything with this signal. When SIGCONT is generated for
a process that is stopped, the process is continued, even if the signal is
blocked or ignored.
Example
The program below demonstrates the normal sequence of code
used when a program handles job control. This program simply copies its
standard input to its standard output, but comments are given in the signal
handler for typical actions performed by a program that manages a screen. When
the program starts, it arranges to catch the SIGTSTP signal only if the signal's disposition is SIG_DFL. The reason is that when the program is started by a shell that
doesn't support job control (/bin/sh, for example), the signal's disposition should
be set to SIG_IGN. In fact,
the shell doesn't explicitly ignore this signal; init sets the disposition of the three job-control signals (SIGTSTP, SIGTTIN, and SIGTTOU) to SIG_IGN. This disposition is then inherited by all login shells. Only a
job-control shell should reset the disposition of these three signals to SIG_DFL.
When we type the suspend character, the process receives the SIGTSTP signal, and the signal handler is invoked. At this point, we would do
any terminal-related processing: move the cursor to the lowerleft corner,
restore the terminal mode, and so on. We then send ourself the same signal, SIGTSTP, after resetting its disposition to its default (stop the process)
and unblocking the signal. We have to unblock it since we're currently handling
that same signal, and the system blocks it automatically while it's being
caught. At this point, the system stops the process. It is continued only when
it receives (usually from the job-control shell, in response to an interactive fg command) aSIGCONT
signal. We don't catch SIGCONT. Its default disposition is to continue the stopped process; when
this happens, the program continues as though it returned from the kill function. When the program is continued, we reset the disposition for
the SIGTSTP signal and do whatever terminal processing we want (we could redraw
the screen, for example).
No comments:
Post a Comment