Page 281 - DCAP403_Operating System

Operating System

Notes each FD an activity counter is kept. When a FD on the mostly inactive list is deemed to be fairly
active, it is migrated to the mostly active list. A reverse operation occurs for fairly inactive FDs
on the mostly active list.

13.8 Inter-process Communication

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 fi rst appeared.

13.8.1 Signals

Signals are one of the oldest inter-process communication methods used by Unix TM systems.
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. You can list a system’s set
of signals using the kill command (kill -l), on my Intel Linux box this gives:
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGIOT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2

13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO

30) SIGPWR
The numbers are different for an Alpha AXP Linux box. 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.
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

274 LOVELY PROFESSIONAL UNIVERSITY