Process Handling in Linux
POS 420
October 11, 2005
In Linux processes communicate with each other and with the kernel to coordinate their
activities. Linux supports a number of Inter-Process Communication (IPC) mechanisms.
Signals and pipes are two of them but Linux also supports the System V IPC mechanisms
named after the Unix TM release in which they first appeared. Signals are one of the oldest
inter-process communication methods used by Unix TM systems. The common Linux
shells all allow redirection. For example $ ls | pr | lpr pipes the output from the ls
command listing the directorys files into the standard input of the pr command which
paginates them. Finally the standard output from the pr command is piped into the standard
input of the lpr command which prints the results on the default printer.
(2005,www.tldp.org)
They are used to signal asynchronous events to one or more processes. A signal could be
generated by a keyboard interrupt or an error condition such as the process attempting to
access a non-existent location in its virtual memory. Signals are also used by the shells to
signal job control commands to their child processes. There are a set of defined signals that
the kernel can generate or that can be generated by other processes in the system, provided
that they have the correct privileges. Processes can choose to ignore most of the signals
that are generated, with two notable exceptions: neither the SIGSTOP signal which causes
a process to halt its execution nor the SIGKILL signal which causes a process to exit can
be ignored. Otherwise though, a process can choose just how it wants to handle the various
signals. Processes can block the signals and, if they do not block them, they can either
choose to handle them themselves or allow the kernel to handle them. If the kernel handles
the signals, it will do the default actions required for this signal. For example, the default
action when a process receives the SIGFPE (floating point exception) signal is to core
dump and then exit. Signals have no inherent relative priorities. If two signals are
generated for a process at the same time then they may be presented to the process or
handled in any order. Also there is no mechanism for handling multiple signals of the same
kind. There is no way that a process can tell if it received 1 or 42 SIGCONT signals.
(2005,www.tldp.org)
Linux implements signals using information stored in the task_struct for the process. The
number of supported signals is limited to the word size of the processor. Processes with a
word size of 32 bits can have 32 signals whereas 64 bit processors like the Alpha AXP may
have up to 64 signals. The currently pending signals are kept in the signal field with a
mask of blocked signals held in blocked. With the exception of SIGSTOP and SIGKILL,
all signals can be blocked. If a blocked signal is generated, it remains pending until it is
unblocked. Linux also holds information about how each process handles every possible
signal and this is held in an array of sigaction data structures pointed at by the task_struct
for each process. Amongst other things it contains either the address of a routine that will
handle the signal or a flag which tells Linux that the process either wishes to ignore this
signal or let the kernel handle the signal for it. The process modifies the default signal
handling by making system calls and these calls alter the sigaction for the appropriate
signal as well as the blocked mask.
Not every process in the system can send signals to every other process, the kernel can and
super users can. Normal processes can only send signals to processes with the same uid
and gid or to processes in the same process group1. Signals are generated by setting the
appropriate bit in the task_structs signal field. If the process has not blocked the signal and
is waiting but interruptible (in state Interruptible) then it is woken up by changing its state
to Running and making sure that it is in the run queue. That way the scheduler will
consider it a candidate for running when the system next schedules. If the default handling
is needed, then Linux can optimize the handling of the signal. For example if the signal
SIGWINCH (the X window changed focus) and the default handler is being used then
there is nothing to be done. (2005,www.tldp.org)
Signals are not presented to the process immediately they are generated., they must wait
until the process is running again. Every time a process exits from a system call its signal
and blocked fields are checked and, if there are any unblocked signals, they can now be
delivered. This might seem a very unreliable method but every process in the system is
making system calls, for example to write a character to the terminal, all of the time.
Processes can elect to wait for signals if they wish, they are suspended in state
Interruptible until a signal is presented. The Linux signal processing code looks at the
sigaction structure for each of the current unblocked signals. If a signals handler is set to
the default action then the kernel will handle it. The SIGSTOP signals default handler will
change the current processs state to Stopped and then run the scheduler to select a new
process to run. The default action for the SIGFPE signal will core dump the process and
