> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-yi-bu-fen-gai-lan/3.3.-xian-jing-yu-zhong-duan.md).

# 3.3 陷阱与中断

陷阱与系统调用一样，对进程同步发生。陷阱可能出自无心之失，如除以零或通过无效指针做间接寻址；进程通过捕获一个信号或被终止来获知问题。陷阱也可能因为缺页而发生，此时系统安排让所需页面可用，然后重启进程，进程根本察觉不到故障发生过。

陷阱处理程序的调用方式与系统调用分发程序相仿：先保存进程状态，再由陷阱处理程序确定陷阱类型，安排投递信号或换入页面；最后检查待决信号，与系统调用处理程序一样地退出。

**I/O 设备中断**

来自 I/O 设备的中断由系统构建时纳入内核的设备驱动模块处理。其他设备的中断由内核的标准组成部分——中断例程——处理。这些例程处理控制台终端接口、实时时钟，以及系统用于低优先级时钟处理和联网设施的若干软件引发的中断。

与由进程同步执行的陷阱和系统调用不同，设备中断异步发生。通常，启动了最终引发中断的操作的进程甚至并不在运行。与陷阱和系统调用一样，必须保存完整的机器状态，因为任何不当改动都会在当前运行的进程中造成不可复现的错误。对请求了服务的进程的通知，只能通过请求让它运行来完成；它运行时自会发现它启动的操作已经完成。

设备中断处理程序只在需要时运行，内核从不调度它们。与系统调用不同，中断处理程序没有每进程上下文。中断处理程序不能指望使用当前运行进程的任何上下文（即进程的 user 结构）。内核通常使用的栈是进程上下文的一部分。有些系统在当前运行进程的内核栈未用部分上接住中断。这种做法要求所有每进程内核栈都足够大，既装得下系统调用，也装得下最深的中断嵌套。VAX 上有一个所有设备中断共用的中断栈。中断发生时，硬件在开始处理中断之前先切换到中断栈。独立的中断栈让每进程内核栈的大小只需按处理同步陷阱或系统调用的需要来确定。

无论中断是在当前每进程栈上处理，还是在独立的中断栈上处理，中断处理程序都不能用那个栈在多次调用之间保存状态。中断处理程序必须从自己的全局工作队列获取并保存全部所需信息。由于没有每进程上下文，它不能为等资源而交出处理器，只能运行到完成再返回。

**软件中断**

内核中的许多事件由硬件中断驱动。对网络控制器这类高速设备，这些中断的优先级很高。对网络控制器来说，重要的是确认收到一个分组并迅速重新使控制器能接受下一个分组，以免丢失接踵而至的分组。然而，把分组交给目的进程的后续处理虽然常常耗时，却不必很快完成。因此，后续处理以较低的优先级进行为好，使关键操作不致被阻塞太久。

做低优先级处理的机制称为软件中断进程（software-interrupt process）。典型地，高优先级中断建立一个较低优先级要做的工作队列。把工作请求入队之后，高优先级中断投递一个在较低优先级运行某函数的请求。当机器优先级降到该低优先级之下时，产生一个中断，调用所请求的函数。函数执行期间若有更高优先级的中断到来，函数被抢占，让高优先级事件先行。

网络分组向目的进程的投递由一个低优先级运行的分组处理函数完成。分组到来时，它们被放进工作队列，控制器随即重新可用。在分组到达的间隙，收包函数努力投递分组。这样，控制器无须等上一个分组投递完就能接受新分组。除网络处理外，软件中断还用来处理时间相关的事件和进程重调度。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-yi-bu-fen-gai-lan/3.3.-xian-jing-yu-zhong-duan.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.