Signals and Interrupts a Comparison

Signals and interrupts a comparison

Interrupts can be viewed as a mean of communication between the CPU and the OS kernel. Signals can be viewed as a mean of communication between the OS kernel and OS processes.

Interrupts may be initiated by the CPU (exceptions - e.g.: divide by zero, page fault), devices (hardware interrupts - e.g: input available), or by a CPU instruction (traps - e.g: syscalls, breakpoints). They are eventually managed by the CPU, which "interrupts" the current task, and invokes an OS-kernel provided ISR/interrupt handler.

Signals may be initiated by the OS kernel (e.g: SIGFPE, SIGSEGV, SIGIO), or by a process(kill()). They are eventually managed by the OS kernel, which delivers them to the target thread/process, invoking either a generic action (ignore, terminate, terminate and dump core) or a process-provided signal handler.

Is my undersanding of Interrupts, Exceptions vs signal definitions correct?

Interrupts

In computing, an interrupt is an asynchronous signal indicating the
need for attention or a synchronous event in software indicating the
need for a change in execution.

(definition obtained from stackoverflow's tag description)

So, it's not unnecessarily asynchronous. It's asynchronous only if it is emitted by the hardware. Think of a virtual device or an emulator for examples of synchronous interrupts, when you are programming a camera and instead of the real device you have an emulator, which you can program to simulate interrupts.

Exceptions

From Microsoft docs:

Most of the standard exceptions recognized by the operating system are
hardware-defined exceptions. Windows recognizes a few low-level
software exceptions, but these are usually best handled by the
operating system.

Windows maps the hardware errors of different processors to the
exception codes in this section. In some cases, a processor may
generate only a subset of these exceptions. Windows preprocesses
information about the exception and issues the appropriate exception
code.

Exceptions are not necessarily hardware-generated and not necessarily synchronous.

If they are synchronous, then a software emitted it (like a camera emulator). Asynchronous exceptions can be raised just about anywhere.

In more advanced programming languages one can use exception handlers and different kinds of exceptions have their own exception subclass. The program can emit an exception with a command, usually the throw keyword which is paired with an exception instance. See: https://www.geeksforgeeks.org/throw-throws-java/

One can implement custom exception classes according to business logic, see https://www.baeldung.com/java-new-custom-exception.

So, the realm of exceptions is much wider than you first thought.

Signals

A signal is a notification to a process that an event occurred. Signals are sometimes described as software interrupts. Signals are analogous to hardware interrupts in that they interrupt the normal flow of execution of a program; in most cases, it is not possible to predict exactly when a signal will arrive. They are defined in the C standards and extended in POSIX, but many other programming languages/systems provide access to them as well.

You are more-or-less correct about signals.

Signals and Interupts When Executing a Program and Killing it

Typing plume in shell

Keyboard interrupts occur. The CPU receives the keyboard interrupts, executes the handler, reads the keycode and scan code etc. An event in generated in /dev/input/event* which will be read either by a terminal emulator program or will get forwarded to the program by your input system. Your desktop environment, Xserver etc are involved.

Hitting the enter key and executing pluma

Same as above. Upon receiving the enter key, the shell would fork() and exec() pluma.

Executing kill pluma_id

Shell process makes the kill() system call. My manual for kill says "The default signal for kill is TERM. Use -l or -L to list available signals". There will be a context switch when the system call is made. After verifying the permissions, the kernel would find the process table entry for the specified process ID. It will update the signal mask for the process in the PTE with the signal number pluma has received.

Thus the signal is delivered to the process. Now the process needs to handle the signal. If it has installed a signal handler for the particular signal, the handler gets called. Else a default handeler/action will be taken by the kernel. In unix systems, signal handling for a process usually happens during a context switch, ie, when the process switches back to user context or when the process gets scheduled again.

The Design of the UNIX Operating System by Maurice J. Bach has a very simple and detailed explanation of the whole process. You might want to have a look at it.

signal & system call usage & relationship

System calls are the rendezvous point between user space and kernel space. It's how normal, user-level code traps into kernel space when something a little more complex needs to be made - reading from a device, writing to a device, changing a hardware configuration, sending network packets, you name it.

So basically, user code interacts with the kernel via syscalls; invoking a syscall is a request to the kernel for a service. While doing so, an interrupt is generated that "wakes up" the kernel. This is called trapping into kernel space.

Signals, on the other hand, are an independent and different communication mechanism. Signals are used by the kernel to asynchronously notify user processes of various events (in some cases, I/O available, or an invalid memory access attempt, or an illegal instruction, etc.), but they are also used between processes: if you have the correct permissions, you can send a signal from a user-space process to another user-space process.

You can set up a custom handler for user-reserved signals such asSIGUSR1 and SIGUSR2 and do whatever pleases you with these. You can use signals to write a basic parent/child synchronization mechanism with the help of sigsuspend(2) and sigaction(2) (and a flag). You can kill an unresponsive process with SIGKILL (although it's advisable that first you try SIGTERM to give it a chance to terminate gracefully).

So, you see, the possibilities are endless. Syscalls are a request to the kernel for a service, adhere to a strictly defined API, and allow you to enter and leave kernel mode for administrative operations. Signals are more like a generic process communication mechanism that also happens to be used by the kernel to notify user processes, but there are other uses.

Is the abrupt ending of a process using Control + C a trap or an interrupt?

The difference between a trap and an interrupt is not as you described in your question (thanks for the reference) but to the asynchronous nature of the events producing it. A trap means an interrupt in the code execution due to a normally incorrect/internal operation (like dividing by zero or a page fault, or as you signaled, a software interrupt), but it ocurrs always at the same place in the code (synchronously with the code execution) and an interrupt occurs because of external hardware, when some device signals the cpu to interrupt what it is doing, as it's ready to send some data. By nature, traps are synchronous and interrupts aren't.

Said this, both are anomalous events that change the normal course of execution of the cpu. Both are hardware produced, but for different reasons: the first occurs synchronously (you know always when, in which instruction, it will be produced, if produced at all) and the second not (you don't know in advance which instruction will be executing when external hardware would assert the interrupt line) Also, there are two kinds of traps (depending on the event that triggered them), one puts the instruction pointer pointing to the next instruction (for example a divide by zero trap) to be executed, and the other puts it pointing to the same instruction that caused the trap (for example a page fault, that has to be reexecuted once the cause of the trap has been corrected) Of course, software interrupts, as by their nature, are always traps (traps that always change the course of execution) as it can be predicted the exact point in the program flow where the cpu will get interrupted.

So, with this explanation, you probably can answer your question yourshelf, a Ctrl-C interrupt is an interrupt as you cannot predice in advance when it will interrupt the cpu execution and you cannot mark that point in your code.

Remember, interrupts ocurr asynchronously, traps not.

What is a signal in Unix?

I cannot believe that people are not comparing things such as hardware and software or stressing OS at some points.

Comparison between a signal and an interrupt:

The difference is that while
interrupts are sent to the operating
system by the hardware, signals are
sent to the process by the operating
system, or by other processes. Note
that signals have nothing to do with
software interrupts, which are still
sent by the hardware (the CPU itself,
in this case). (source)

Definitions

1. process = a program in execution, according to the book below

Further reading

1. compare the signal to Interrupts and Exceptions

2. Tanenbaum's book Modern Operating Systems

---

Related Topics