Linux 信号和中断比较

Signals and interrupts a comparison

提问by Vivek Maran

Based on various references, my subjective definition of signals in Linux is "The triggers that are used to notify the processes about an occurrence of a specific event.Event here may refer to a software exception.Additionally signals may also be used for IPC mechanisms."The questions I have are

基于各种参考资料，我对Linux中信号的主观定义是“用于通知进程发生特定事件的触​​发器。这里的事件可能指的是软件异常。另外，信号也可以用于IPC机制。 ” 我的问题是

• I presume only exceptions (software interrupts) are notified via signals.What about the case of hardware interrupts.
• What are the various sources of the signal? To me it looks like kernel is always the source of a signal.(except when used for IPC)
• Difference between the signal handler and the ISR?.
• Difference between signal blocking and interrupt masking?

• 我认为只有异常（软件中断）通过信号通知。硬件中断的情况如何。
• 信号的各种来源是什么？在我看来，内核始终是信号的来源。（用于 IPC 时除外）
• 信号处理程序和 ISR 之间的区别？。
• 信号阻塞和中断屏蔽的区别？

采纳答案by ninjalj

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.

中断可以被视为 CPU 和操作系统内核之间的一种通信方式。信号可以被视为操作系统内核和操作系统进程之间通信的一种方式。

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.

中断可以由 CPU（异常 - 例如：除以零、页面错误）、设备（硬件中断 - 例如：输入可用）或 CPU 指令（陷阱 - 例如：系统调用、断点）发起。它们最终由 CPU 管理，它“中断”当前任务，并调用操作系统内核提供的 ISR/中断处理程序。

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.

信号可以由操作系统内核（例如：SIGFPE、SIGSEGV、SIGIO）或进程（kill()）发起。它们最终由操作系统内核管理，操作系统内核将它们传递给目标线程/进程，调用通用操作（忽略、终止、终止和转储核心）或进程提供的信号处理程序。

回答by Simon Richter

Signals and interrupts behave in pretty similar ways. The difference is that signals happen to a process (which lives in a virtual environment), while exceptions are system-wide.

信号和中断的行为方式非常相似。不同之处在于信号发生在一个进程（位于虚拟环境中），而异常是系统范围的。

Certain faults are flagged by the CPU as an exception, and then mapped to a signal that is delivered to the process by the kernel. The kernel can choose to hide any exception from the process (for example, accesses to unmapped memory are silently fixed up by paging).

某些故障被 CPU 标记为异常，然后映射到内核传递给进程的信号。内核可以选择对进程隐藏任何异常（例如，对未映射内存的访问通过分页静默修复）。

Hardware interrupts are simply a kind of exception, which the kernel may choose to map to a signal (for example, if you use alarm(2)).

硬件中断只是一种异常，内核可能会选择将其映射到信号（例如，如果您使用alarm(2)）。

The kernel generates signals in response to various events, among them exceptions, I/O completion, explicit userspace requests, ...

内核生成信号以响应各种事件，其中包括异常、I/O 完成、显式用户空间请求……

Signal handlers behave similarly to ISRs -- they can be invoked at any time, so they cannot make any assumptions about the state of the program, just like ISRs -- and blocking signals behaves the same way inside the virtual address space as masking interrupts does on the physical machine.

信号处理程序的行为与 ISR 类似——它们可以随时被调用，因此它们不能像 ISR 一样对程序的状态做出任何假设——并且阻塞信号在虚拟地址空间内的行为与屏蔽中断相同在物理机上。

回答by christopher

I presume only exceptions (software interrupts) are notified via signals.What about the case of hardware interrupts.

我认为只有异常（软件中断）通过信号通知。硬件中断的情况如何。

Where to begin ? There's lots of different cases. Keep in mind that interrupts are the hardware calling the cpu. Interrupts essentially consist of "hardware needs attention" and a number between 0 and 255. Signals are similar but have 2 parameters : destination process id and an int (32 bit or 64 bits, depending on arch). Hardware interrupts are always handled in kernel space, whereas signals are user-space only things. The kernel uses hardware interrupts for various reasons.

从哪里开始？有很多不同的情况。请记住，中断是调用 CPU 的硬件。中断基本上由“硬件需要注意”和 0 到 255 之间的数字组成。信号类似但有 2 个参数：目标进程 ID 和一个 int（32 位或 64 位，取决于 arch）。硬件中断总是在内核空间处理，而信号只是用户空间的东西。内核出于各种原因使用硬件中断。

One example of a hardware interrupt that has nothing to do with signals is the VM subsystem. You know that on modern operating systems you can allocate more memory than actually exists on the system. So how does this work ? Well it works by exploiting hardware interrupts. When you allocate memory, the kernel takes a note of it, but doesn't actually do anything at all. Then, when you try to access the allocated memory, the cpu is going to complain "but this memory doesn't exist", which will generate a hardware interrupt. The kernel will go and look through it's notes, find that you indeed requested that memory, clear some memory it has free, and tell the cpu to "map" that memory in the expected location. After which the kernel resumes your program at the point just before the hardware interrupt occured and this time the process will find the memory just fine.

与信号无关的硬件中断的一个例子是 VM 子系统。您知道，在现代操作系统上，您可以分配比系统上实际存在的内存更多的内存。那么这是如何工作的呢？好吧，它通过利用硬件中断来工作。当您分配内存时，内核会记录下来，但实际上根本不做任何事情。然后，当您尝试访问分配的内存时，cpu 会抱怨“但此内存不存在”，这将产生硬件中断。内核将查看它的注释，发现您确实请求了该内存，清除它空闲的一些内存，并告诉 cpu 将该内存“映射”到预期位置。

Multitasking is also implemented through exploiting a hardware interrupt. All drivers generally work by interpreting interrupts.

多任务处理也是通过利用硬件中断来实现的。所有驱动程序通常通过解释中断来工作。

Signals are used to communicate between processes. Something very "signal-y" would be the common behaviour for linux daemons to reload their configuration on SIGHUP, loved and hated by sysadmins all over the places. When you modify, say, an apache config, the process does not automatically start using the new config. You might terminate and restart the process, but that means that 4-5 seconds your http server is going to be out of the air. So instead you might "killall -HUP apache". This is going to call a subroutine in the apache process, which will make it re-read it's config file.

信号用于进程之间的通信。linux 守护进程在 SIGHUP 上重新加载他们的配置是非常“信号-y”的常见行为，受到各地系统管理员的喜爱和憎恨。例如，当您修改 apache 配置时，该过程不会自动开始使用新配置。您可以终止并重新启动该过程，但这意味着您的 http 服务器将在 4-5 秒内停止运行。因此，您可能会“killall -HUP apache”。这将在 apache 进程中调用一个子程序，这将使它重新读取它的配置文件。

Process suspending is implemented through signals (ctrl-z), process interrupting (ctrl-c), process quitting (ctrl-), terminal disconnects (sighup), ... a more complete list can be found here : http://en.wikipedia.org/wiki/Unix_signal.

进程挂起是通过信号（ctrl-z）、进程中断（ctrl-c）、进程退出（ctrl-）、终端断开（sighup）……更完整的列表可以在这里找到：http://en .wikipedia.org/wiki/Unix_signal。

One conclusion might be that they're sort-of similar, but they operate at a different level : hardware interrupts are, well, the hardware crying for attention, and the lowest level software obliges. Generally the kernel handles all hardware, and informing processes is done somewhat independant of the hardware interrupts. For a number of signals default handling is provided (e.g. ctrl-z, ctrl-c, ...), for others the implementation is very application dependant (e.g. SIGHUP).

一个结论可能是它们有点相似，但它们在不同的级别运行：硬件中断是，嗯，硬件需要注意，而最低级别的软件有义务。通常内核处理所有硬件，通知进程在某种程度上独立于硬件中断。对于许多信号，提供了默认处理（例如 ctrl-z、ctrl-c、...），对于其他信号，实现非常依赖于应用程序（例如 SIGHUP）。

When it comes to signals, well these are just software-defined. They do whatever you may want them to do, and linux comes with convenient methods to call these subroutines. In some cases the kernel might call a signal routine (e.g. SIGSEGV, SIGCHILD, ...), but it hardly ever involves hardware. They're just a convenient way to trigger a specific routine in an application.

说到信号，这些只是软件定义的。他们做你想让他们做的任何事情，而 linux 提供了方便的方法来调用这些子程序。在某些情况下，内核可能会调用信号例程（例如 SIGSEGV、SIGCHILD 等），但它几乎不涉及硬件。它们只是在应用程序中触发特定例程的便捷方式。

There used to be a special case : the "OS" interrupt, in DOS 21h. This is no longer used (though still works), but the idea is this. A program can trigger a specific interrupt to ask the kernel to perform specific actions. The actions being the syscalls (opening a file, closing a socket, what have you). As I said, interesting, but no longer really used.

曾经有一种特殊情况：DOS 21h 中的“OS”中断。这不再使用（尽管仍然有效），但想法是这样的。程序可以触发特定的中断来要求内核执行特定的操作。动作是系统调用（打开文件，关闭套接字，你有什么）。正如我所说，有趣，但不再真正使用。

What are the various sources of the signal? To me it looks like kernel is always the source of a signal.(except when used for IPC)

信号的各种来源是什么？在我看来，内核始终是信号的来源。（用于 IPC 时除外）

A signal either comes from the process itself (SIGABRT), from the kernel (SIGSEGV, ...) or from other processes, like the shell for example (ctrl-z, ctrl-c, ctrl-\, ...) or from kill. But they can come from any other program through using the kill libc function :

信号要么来自进程本身 (SIGABRT)，来自内核 (SIGSEGV, ...) 或来自其他进程，例如 shell (ctrl-z, ctrl-c, ctrl-\, ...) 或从杀。但是它们可以通过使用 kill libc 函数来自任何其他程序：

   #include <sys/types.h>
   #include <signal.h>

   int kill(pid_t pid, int sig);

Difference between the signal handler and the ISR?.

信号处理程序和 ISR 之间的区别？。

The main difference is that ISRs live in kernel space and have to take into account that the entire computer is frozen during their execution. This means that they can have interrupted any process, and anything in the kernel. They also "stop the world". While an interrupt is being handled, nothing else will happen. So if an interrupt handler waits for something, the machine freezes. If an interrupt handler goes into a loop, your only option is rebooting the machine.

主要区别在于 ISR 存在于内核空间中，并且必须考虑到整个计算机在其执行过程中都处于冻结状态。这意味着它们可以中断任何进程和内核中的任何内容。他们还“停止了世界”。在处理中断时，不会发生其他任何事情。因此，如果中断处理程序等待某事，机器就会冻结。如果中断处理程序进入循环，您唯一的选择就是重新启动机器。

ISRs are REALLY hard to get right. There's lots of theory on them, on linux they have top half and bottom half sections, with all sorts of priority handling, special memory allocation, ... and it's a minefield. One step in the wrong direction in an ISR will kill the machine. A bug in an ISR will cause dataloss, maybe even outright hardware failure. In fact speaking from experience, merely raising suspicion that you might be planning to do something wrong in an ISR immediately results in completely unpredictable machine behavior.

ISR 真的很难做到正确。关于它们有很多理论，在 linux 上，它们有上半部分和下半部分，具有各种优先级处理、特殊内存分配，......这是一个雷区。在 ISR 中朝错误方向迈出的一步将杀死机器。ISR 中的错​​误会导致数据丢失，甚至可能是彻底的硬件故障。事实上，根据经验，仅仅怀疑您可能计划在 ISR 中做错事，就会立即导致完全不可预测的机器行为。

You can't use any kernel facilities in ISRs. Opening a file, forget it. Allocating memory, forget it. Calling any other part of the kernel, forget it (with a few, but only a few, exceptions). The list goes on.

您不能在 ISR 中使用任何内核设施。打开一个文件，忘记它。分配内存，算了。调用内核的任何其他部分，忘记它（有一些，但只有少数例外）。名单还在继续。

Signals are just functions in specific processes getting called. A signal can block (e.g. ctrl-z) and this will stop the process from making progress, but for example your shell session will still respond. The process needs to take into account that any part of the program may have been interrupted of course, but it's still normal user space. You can block, you can loop, you can open files, allocate memory, ... whatever you want.

信号只是特定进程中被调用的函数。信号可以阻塞（例如 ctrl-z），这将阻止进程取得进展，但例如您的 shell 会话仍将响应。这个过程需要考虑到程序的任何部分当然可能已经被中断了，但它仍然是正常的用户空间。你可以阻塞，你可以循环，你可以打开文件，分配内存，......任何你想要的。

Difference between signal blocking and interrupt masking?

信号阻塞和中断屏蔽的区别？

They're quite similar. Except signal blocking is done on a per-process basis. In both cases there are unblockable signals, and there is a NMI (non maskable interrupt) (both indicate serious errors).

他们非常相似。除了信号阻塞是在每个进程的基础上完成的。在这两种情况下都有不可阻塞的信号，并且有一个 NMI（不可屏蔽中断）（两者都表示严重错误）。

In the end signals and interrupts are sending a number, either to the kernel or to a specific processes. Signal blocking and interrupt masking just means telling the system to ignore specific numbers.

最后，信号和中断会向内核或特定进程发送一个数字。信号阻塞和中断屏蔽只是告诉系统忽略特定数字。

One difference is that interrupt masking is implemented in hardware.

一个区别是中断屏蔽是在硬件中实现的。