Signals and Interrupts in Unix/Linux

Interrupts are external requests from I/O devices or coprocessors sent to a CPU, which divert the CPU from its normal executions to do interrupt processing. Like interrupts to a CPU, signals are requests sent to a process, which divert the process from its normal executions to do signal processing. Before discussing signals and signal processing, we shall review the concepts and mechanism of interrupts, which help put signals into a proper perspective.

(1). First, we generalize the notion of process to mean: a “process” (in quotes) is a sequence of activities. Examples of generalized “processes” include .

. a person, who carries on his/her daily routine chores.

. a Unix/Linux process, which runs in either user mode or kernel mode.

. a CPU, which executes machine instructions.

(2) . An “interrupt” is an event sent to a “process”, which diverts the “process” from its normal activities to do something else, called “interrupt processing”.

The “process” may resume its normal activities after it finishes processing the “interrupt”.

(3) . The term “interrupt” can be applied to any “process”, not just to a CPU in a computer. For example, we may speak of the following kinds of “interrupts”.

(3).1. PERSON interrupts

While I am reading, grading, day-dreaming, etc. in my office, some real events may occur, such as

All these may be called PERSON interrupts because they divert a person from his/her normal activities to “handle or process the interrupt”. After processing an interrupt, a person may resume whatever he/she was doing before (if the person survives and still remembers what he/she was doing before). Each interrupt is assigned a unique ID number for identification, and has a pre-installed action function, which a person can “execute” upon receiving an interrupt. Depending on their origin, interrupts may be classified into 3 categories:

From hardware : building on fire, alarm clock goes off, etc.

From other person: phone call, knocking on door, etc.

Self-inflicted          : cut own finger, eat too much, etc.

Depending on their urgency, interrupts can be classified as

Non-maskable (NMI): Building on fire!

Maskable                     : Knocking on door, etc.

Each of the action functions of a PERSON is installed either by instincts or by experience. It is impossible to complete the above table since there are too many different kinds of PERSON interrupts, but the idea should be clear.

(3).2. PROCESS interrupts

These are interrupts sent to a process. While a process is executing, it may receive interrupts from 3 different sources:

From hardware : Control_C key from terminal, interval timer, etc.

From other process: kill(pid, SIG#), death_of_child, etc.

Self-inflicted          : divide by zero, invalid address, etc.

Each process interrupt is converted to a unique ID number, which is sent to the process. Unlike PERSON interrupts, which has too many kinds, we can always limit the number of interrupts to a process. In Unix/Linux, process interrupts are called SIGNALS, which are numbered 1 to 31. For each signal, a process has an action function in its PROC structure, which the process can execute upon receiving a signal. Similar to a person, a process may mask out certain kinds of signals to defer their processing. If needed, a process may also change its signal action functions.

(3).3. HARDWARE Interrupts:

These are signals sent to a processor or CPU. They also originate from 3 possible sources:

From hardware : Timer, I/O devices, etc.

From other processors: FFP, DMA, other CPUs in a multiprocessor system.

Self-inflicted               : divide by 0, protection error, INT instruction.

Each interrupt has a unique interrupt vector number. The action function is an interrupt handler in the interrupt vector table. Recall that a CPU is always executing a process. The CPU does not cause any self-inflicted interrupts (unless faulty). Such interrupts are due to the process that is using or, in most cases, misusing the CPU. The former includes the INT n or equivalent instructions, which cause the CPU to switch from user mode to kernel mode. The latter includes all trap errors recognized by the CPU as exceptions. Therefore, we may rule out the self-inflicted interrupts from a CPU, leaving only those external to the CPU.

(3).4. Trap Errors of Process

A process may cause self-inflicted interrupts to itself. Such interrupts are due to errors, e.g. divide by 0, invalid address, illegal instruction, privilege violation, etc. which are recognized by the CPU as exceptions. When a process encounters an exception, it traps to the OS kernel, converts the trap reason to a signal number and sends the signal to itself. If the exception occurs in user mode, the default action of a process is to terminate, with an optional memory dump for debugging. As we shall see later, a process may replace the default action function with a signal catcher, allowing it to handle signal in user mode. If the trap occurs in kernel mode, which must be due to hardware error or, most likely, bugs in the kernel code, there is nothing the kernel can do. In Unix/Linux, the kernel simply prints a PANIC error message and stops. Hopefully the problem can be traced and fixed in the next kernel release.

Source: Wang K.C. (2018), Systems Programming in Unix/Linux, Springer; 1st ed. 2018 edition.

Leave a Reply

Your email address will not be published. Required fields are marked *