Linux优秀的系统--信号（3--信号的保存、阻塞）

// 这是5.6.1版本的Linux系统中的task_struct部分代码
struct task_struct {
// ...
/* Signal handlers: */
struct signal_struct        *signal;        // (1) 进程组共享的信号信息
struct sighand_struct __rcu    *sighand;    // (2) 指向信号处理程序描述符
sigset_t            blocked;        // (3) 当前线程的信号屏蔽字（阻塞掩码）
sigset_t            real_blocked;    // (4) 临时信号屏蔽字（用于TIF_SIGPENDING）
/* Restored if set_restore_sigmask() was used: */
sigset_t            saved_sigmask;    // (5) 保存的信号屏蔽字（用于系统调用重启等）
struct sigpending        pending;    // (6) 挂起（未决）信号队列
// ...
};

1. struct signal_struct *signal; // 不是本节重点，简单了解

作用： 这是一个指向 signal_struct结构体的指针。这个结构体包含了整个线程组（通常就是一个进程及其所有线程）共享的信号相关信息。
关键内容 (signal_struct内部)：
- struct sigpending shared_pending;: 共享的挂起信号队列。这是发送给整个线程组的信号（例如，通过 kill(pid, sig)发送给进程 PID）的存放位置。所有线程共享这个队列。当内核需要向线程组发送信号时，信号会先放在这里。
- struct rlimit rlim[RLIM_NLIMITS];: 进程资源限制。这些限制（如最大文件打开数 RLIMIT_NOFILE、最大栈大小 RLIMIT_STACK等）是进程级别的，所有线程共享相同的限制。
- int group_exit_code;: 线程组退出状态码。当线程组开始退出时（例如，主线程退出或收到终止信号），这个字段存储退出状态。
- struct task_struct *group_exit_task;: 执行线程组退出的任务。指向负责执行线程组退出流程（如调用 do_exit()）的任务。
- struct tty_struct *tty;: 控制终端。记录进程的控制终端信息，与控制终端相关的信号（如 SIGHUP, SIGTTOU）处理需要用到。
- struct pid *tty_old_pgrp;: 旧的终端前台进程组 ID。用于作业控制。
- int leader;: 是否为会话首进程 (Session Leader)。
- struct list_head thread_head;: 线程链表头。指向该线程组中所有线程的 task_struct链表。
- wait_queue_head_t wait_chldexit;: 等待子进程退出的等待队列。waitpid()等系统调用会用到。
- ...(还有其他成员，如统计信息、计时器等)。
重要性：signal_struct是进程级别（线程组级别） 信号信息的容器。它确保了属于同一个进程的所有线程在资源限制、控制终端、共享信号处理等方面具有一致的视图。shared_pending是实现“发送给进程的信号能被任意线程处理”的关键。

2. struct sighand_struct __rcu *sighand; // 重点

作用： 这是一个指向 sighand_struct结构体的指针（使用 __rcu注解，表示通过 RCU 机制保护，用于安全并发访问）。这个结构体包含了该线程（任务）的信号处理程序定义。
关键内容 (sighand_struct内部)：
- atomic_t count;: 引用计数器。因为 sighand_struct可以在线程间共享（默认情况下，新线程继承父线程的信号处理设置），或者被克隆（CLONE_SIGHAND标志）。count记录有多少个 task_struct引用了这个 sighand_struct。
- struct k_sigaction action[_NSIG];: 信号处理动作数组。这是最核心的部分！它是一个数组，索引对应信号编号（SIGKILL和 SIGSTOP的处理程序虽然无效，但位置保留）。每个 struct k_sigaction元素定义了当信号 signum递达时，内核应该执行的动作：
```
struct k_sigaction {
struct sigaction sa; // 兼容用户空间的 sigaction 结构
// 或者更常见的内核内部表示：
// void (*handler)(int); // 用户空间处理函数地址 (SIG_DFL, SIG_IGN, 或用户函数)
// unsigned long flags;   // 标志位 (SA_RESTART, SA_SIGINFO, SA_NOCLDSTOP 等)
// void (*restorer)(void); // 恢复函数 (通常由 libc 提供，用于恢复上下文)
// sigset_t mask;         // 执行此信号处理程序时阻塞的信号集
};
```
  - handler: 指定处理方式：SIG_DFL(默认动作), SIG_IGN(忽略), 或用户自定义函数的地址。
  - flags: 控制处理行为的标志，如 SA_RESTART(被信号中断的系统调用自动重启), SA_SIGINFO(处理程序需要额外信息，使用 sa_sigaction而非 sa_handler), SA_NOCLDSTOP(子进程停止时不产生 SIGCHLD) 等。
  - mask: 当内核正在执行这个特定信号的处理程序时，自动阻塞哪些其他信号。这通常包括被处理的信号本身（防止递归中断），也可以包括用户指定的其他信号。
- spinlock_t siglock;: 自旋锁。用于保护对 sighand_struct的并发访问（例如，修改 action数组）。
重要性：sighand_struct定义了线程如何响应信号。action数组存储了每个信号的具体处理程序、标志和屏蔽字。count和 siglock确保了在多线程环境下安全地访问和修改这些处理程序。每个线程可以有自己的 sighand_struct（如果使用了 CLONE_SIGHAND则共享），这使得线程可以独立修改自己的信号处理方式（尽管共享 signal_struct中的其他信息）。

3. sigset_t blocked; // 重点

作用： 这是当前线程的信号屏蔽字 (Signal Mask)。它是一个位图（sigset_t类型），每一位代表一个信号。
工作原理：
- 如果某个信号对应的位在 blocked中被置位（=1），则表示该信号当前被此线程阻塞。
- 当一个被阻塞的信号产生时（无论是发送给线程还是线程组），它不会立即递达给这个线程。对于线程私有信号，它会被放入该线程的 pending队列（见下文）。对于线程组共享信号，它会被放入 signal->shared_pending队列。
- 只有当该信号在 blocked中的位被清除（=0）时（通过 sigprocmask/pthread_sigmask），内核才会检查 pending或 shared_pending中是否有该信号的未决实例，并尝试递达它。
操作： 线程通过 sigprocmask(单线程进程) 或 pthread_sigmask(多线程进程) 系统调用修改自己的 blocked掩码。
例外：SIGKILL(9) 和 SIGSTOP(19) 不能被阻塞。尝试将它们添加到 blocked掩码的操作会被内核忽略。
重要性：blocked是线程主动控制信号递达时机的主要机制。它保护代码关键区域不被信号中断，或延迟处理非关键信号。

4. sigset_t real_blocked; // 较为重点

作用： 这是一个临时的信号屏蔽字。它的主要用途与内核内部的 TIF_SIGPENDING标志位协作。
工作原理：
- 当内核需要为一个线程处理未决信号时（例如，在从系统调用或中断返回用户空间之前），它会检查线程的 TIF_SIGPENDING标志是否被设置（表示有待处理信号）。
- 在实际调用信号处理程序之前，内核会执行一个关键操作：
  1. 将线程当前的 blocked掩码临时保存到 real_blocked中。
  2. 将线程的 blocked掩码替换为即将执行的信号处理程序的 mask（定义在 sighand->action[signum].sa.mask中）。这通常包括阻塞当前正在处理的信号本身（防止递归）以及用户指定的其他信号。
- 这样，在信号处理程序执行期间，blocked掩码反映的是处理程序要求的屏蔽集。
- 当信号处理程序返回后，内核通过 sigreturn系统调用（通常由 restorer函数触发）恢复线程原始的 blocked掩码（从 real_blocked复制回来）。
重要性：real_blocked是实现信号处理程序执行期间临时修改信号屏蔽字这一语义的关键。它保存了信号处理程序执行前线程的“真实”阻塞状态，以便在处理程序结束后恢复。用户通常不直接操作 real_blocked，它由内核在信号递达流程中自动管理。

5. sigset_t saved_sigmask; // 简单了解

作用： 用于保存和恢复线程的信号屏蔽字，主要服务于特定的系统调用行为（如 pselect(), ppoll(), epoll_pwait()）和 pthread同步原语。
工作原理：
- 当线程调用一个设计为临时解除信号阻塞并等待事件的系统调用（如 pselect(nfds, readfds, writefds, exceptfds, timeout, sigmask)）时：
  1. 内核会将线程当前的 blocked掩码保存到 saved_sigmask中。
  2. 将线程的 blocked掩码临时设置为用户传入的 sigmask参数（通常是一个在等待期间希望解除阻塞的信号集）。
  3. 然后线程进入等待状态。
- 当等待的事件发生（或超时）后，线程从系统调用返回。
- 在返回用户空间之前，内核会将 saved_sigmask中的值恢复到 blocked掩码中。
与 set_restore_sigmask()： 内核函数 set_restore_sigmask()用于设置一个标志，告诉内核在系统调用退出路径上需要执行上述的恢复操作（将 saved_sigmask恢复到 blocked）。注释 /* Restored if set_restore_sigmask() was used: */明确指出了这一点。
重要性：saved_sigmask使得系统调用能够原子地修改信号屏蔽字并进入等待状态，并在返回时自动恢复之前的屏蔽状态。这避免了在用户空间手动保存、修改、恢复屏蔽字可能出现的竞态条件。

6. struct sigpending pending; // 重点 // 实时信号部分可以仅作简单了解

作用： 存储发送给这个特定线程的、尚未递达（未决）的信号。
结构 (struct sigpending内部)：
```
struct sigpending {
struct list_head list;  // (6a) 挂起信号链表的头
sigset_t signal;        // (6b) 挂起信号位图
};
```
- sigset_t signal;(6b): 一个位图，每一位代表一个信号。如果某位被置位（=1），表示至少有一个该类型信号的实例正挂起（未决）在此线程的队列中。对于标准信号 (1-31)： 内核通常只记录“有”或“无”，多次发送同一标准信号可能只在该位图上体现一次（非队列化）。对于实时信号 (34-64)： 该位图仅表示存在挂起的实时信号，具体次数和顺序由链表管理。
- struct list_head list;(6a): 一个链表头，链接所有挂起的实时信号实例。每个挂起的信号（主要是实时信号）由一个 struct sigqueue结构表示：
```
struct sigqueue {
struct list_head list; // 链表节点
int flags;             // 标志 (如 SIGQUEUE_PREALLOC)
siginfo_t info;        // (6c) 携带的信号信息
struct user_struct *user; // 资源计数的用户
};
```
  - siginfo_t info;(6c): 这是最重要的成员。它包含了关于信号的详细信息：
    - int si_signo;: 信号编号。
    - int si_code;: 信号来源代码（如 SI_USER, SI_KERNEL, SI_QUEUE, SI_TIMER, SI_ASYNCIO等）。
    - union：一个联合体，包含信号相关的附加数据。例如：
      - 发送者 PID (pid_t si_pid;)
      - 发送者 UID (uid_t si_uid;)
      - 定时器 ID (void *si_tid;)
      - 用户自定义值 (int si_int; void *si_ptr;)
      - 导致信号的地址 (void *si_addr;)
      - 导致信号的文件描述符 (int si_fd;)
      - 子进程退出状态 (int si_status;) 等。
信号入队：
- 当信号被发送给一个特定线程（例如，使用 pthread_kill()或 tgkill()）时，内核会尝试将其放入目标线程的 pending.list链表（实时信号）或设置 pending.signal位图（标准信号）。
- 发送给线程组（进程）的信号（使用 kill()）会被放入 signal->shared_pending。
信号递达：
- 当内核决定为线程递达一个信号时：
  1. 对于标准信号：通常从 pending.signal位图判断是否存在，然后根据 sighand->action[]执行动作。递达后清除位图中的对应位。
  2. 对于实时信号（或需要 siginfo的标准信号）：内核会从 pending.list链表中取出一个 struct sigqueue，提取其中的 siginfo_t信息，传递给信号处理程序（如果设置了 SA_SIGINFO）。处理完毕后，释放该 sigqueue结构。如果链表空了，则清除 pending.signal中的对应位。
重要性：pending结构是线程私有未决信号队列的核心。list链表实现了实时信号的队列化（FIFO），确保多次发送的实时信号都能被依次处理。signal位图提供了快速判断是否有任何类型信号挂起的方式。siginfo_t使得信号处理程序能够获取关于信号来源和原因的详细信息。

总结:

signal_struct: 进程(线程组)级别的共享信息（共享挂起信号、资源限制、控制终端等）。
sighand_struct: 线程级别的信号处理程序定义（处理函数、标志、处理时屏蔽字）。
blocked: 线程当前生效的信号屏蔽字（阻塞掩码）。
real_blocked: 保存信号处理程序执行前屏蔽字的临时存储，用于在信号处理期间应用处理程序指定的屏蔽字。
saved_sigmask: 保存系统调用/等待前屏蔽字，用于在特定系统调用返回后恢复原始屏蔽字。
pending: 线程私有的挂起（未决）信号队列（链表用于实时信号队列化和携带 siginfo，位图用于快速检测）。

这些结构体成员紧密协作，共同实现了 Linux 内核复杂而强大的信号处理机制，涵盖了信号产生、阻塞、挂起、递达、处理程序执行、屏蔽字管理以及进程/线程组语义等各个方面。

与信号阻塞相关的系统调用

相关函数的详细讲解在：Linux系统–信号–信号屏蔽（阻塞）核心函数-CSDN博客

简略讲解：

核心函数：sigprocmask和 pthread_sigmask

辅助函数：操作信号集 (sigset_t)

要使用 sigprocmask或 pthread_sigmask，你需要能够创建和操作 sigset_t类型的信号集。以下是最常用的函数：

让一个进程阻塞某个信号的具体使用流程

以下流程以单线程进程使用 sigprocmask为例。如果是多线程程序中的某个线程，只需将 sigprocmask替换为 pthread_sigmask。

目标： 让进程在执行一段关键代码（临界区）时阻塞 SIGINT(Ctrl+C) 信号，防止被中断。执行完临界区后恢复原来的信号屏蔽状态。

步骤：

声明变量：

#include <signal.h>sigset_t new_mask, old_mask; // 定义新的信号集和用于保存旧信号集的变量

初始化新的信号集：

if (sigemptyset(&new_mask) == -1) {
perror("sigemptyset");
exit(EXIT_FAILURE);
}

创建一个空的信号集 new_mask。

添加要阻塞的信号：

if (sigaddset(&new_mask, SIGINT) == -1) { // 将 SIGINT 添加到 new_mask
perror("sigaddset");
exit(EXIT_FAILURE);
}
// 如果需要阻塞多个信号，可以多次调用 sigaddset
// if (sigaddset(&new_mask, SIGQUIT) == -1) { ... }

设置新的阻塞信号集 (屏蔽字)，并保存旧的：
```
if (sigprocmask(SIG_BLOCK, &new_mask, &old_mask) == -1) {
perror("sigprocmask");
exit(EXIT_FAILURE);
}
```
- SIG_BLOCK: 表示我们要将 new_mask中的信号 (SIGINT) 添加到当前阻塞集中。
- &old_mask: 函数会将修改前的阻塞集保存在 old_mask中，以便后续恢复。

执行临界区代码：

/* 这里是你的关键代码区域 (临界区) */
/* 在此区域执行期间，SIGINT 信号将被阻塞。如果用户按下 Ctrl+C，
信号会被标记为未决 (pending)，但不会递达 (执行处理程序或终止进程)，
直到我们解除阻塞。 */
do_critical_work();

恢复旧的阻塞信号集：
```
if (sigprocmask(SIG_SETMASK, &old_mask, NULL) == -1) {
perror("sigprocmask (restore)");
exit(EXIT_FAILURE);
}
```
- SIG_SETMASK: 表示我们要直接将阻塞集设置为 old_mask的值（即恢复之前的阻塞状态）。
- NULL: 因为我们不需要再次保存当前（即将被替换的）阻塞集，所以第三个参数设为 NULL。
- 关键点： 在恢复旧屏蔽字 (old_mask) 的过程中，内核会检查 SIGINT是否在恢复后被解除了阻塞（即 old_mask是否阻塞 SIGINT？）。如果 old_mask不阻塞SIGINT，并且在我们阻塞期间有 SIGINT信号产生（处于未决状态），那么内核会立即递达这个 SIGINT信号（执行默认动作终止进程，或执行用户注册的处理函数）。

完整示例代码 (单线程)：

#include <stdio.h>#include <stdlib.h>#include <signal.h>#include <unistd.h> // for sleepvoid do_critical_work(void) {printf("Entering critical section...\n");sleep(5); // 模拟耗时操作，期间可以尝试按 Ctrl+Cprintf("Exiting critical section.\n");}int main(void) {sigset_t new_mask, old_mask;// 1. 创建空信号集if (sigemptyset(&new_mask) == -1) {perror("sigemptyset");exit(EXIT_FAILURE);}// 2. 添加 SIGINT 到新信号集if (sigaddset(&new_mask, SIGINT) == -1) {perror("sigaddset");exit(EXIT_FAILURE);}// 3. 阻塞 SIGINT，并保存旧屏蔽字if (sigprocmask(SIG_BLOCK, &new_mask, &old_mask) == -1) {perror("sigprocmask (block)");exit(EXIT_FAILURE);}// 4. 执行临界区代码 (此时 SIGINT 被阻塞)do_critical_work();// 5. 恢复旧的信号屏蔽字 (解除对 SIGINT 的阻塞)if (sigprocmask(SIG_SETMASK, &old_mask, NULL) == -1) {perror("sigprocmask (restore)");exit(EXIT_FAILURE);}// 如果临界区期间产生了 SIGINT，并且旧屏蔽字不阻塞它，这里可能会立即递达 SIGINT!printf("Back to normal state. You can now interrupt with Ctrl+C.\n");pause(); // 等待一个信号 (方便测试)return 0;}

运行与观察：

编译并运行程序。
在程序打印 "Entering critical section..."并开始睡眠的 5 秒内，按下 Ctrl+C。
你会发现程序没有立即退出！它继续完成了睡眠，打印 "Exiting critical section."，然后打印 "Back to normal state..."。
这证明 SIGINT在临界区被成功阻塞了。信号被标记为未决 (pending)。
当调用 sigprocmask(SIG_SETMASK, &old_mask, NULL)恢复旧屏蔽字（通常旧屏蔽字不阻塞 SIGINT）时，内核检测到未决的 SIGINT并立即递达它。因为 SIGINT的默认动作是终止进程，所以程序会在恢复屏蔽字后立即退出，可能来不及打印最后一条信息或只打印一部分。要看到最后一条信息，你可以为 SIGINT注册一个处理函数，在函数里打印信息而不是直接退出。

多线程程序注意事项：

在 main函数创建任何线程之前，主线程可以使用 sigprocmask设置初始屏蔽字，这些设置通常会被新创建的线程继承。
在任何线程（包括主线程）中需要修改自身的信号屏蔽字时，必须使用 pthread_sigmask。
发送给进程的信号 (kill(pid, sig)) 会进入 shared_pending队列，可以被任意一个不阻塞该信号的线程处理。
发送给特定线程的信号 (pthread_kill(tid, sig)) 会进入目标线程的私有 pending队列，只有该线程自己能处理（当其解除阻塞时）。

总结关键流程：

准备信号集： 使用 sigemptyset, sigaddset(或 sigfillset, sigdelset) 构建一个包含你希望阻塞的信号的 sigset_t。
阻塞信号 (设置屏蔽字)： 使用 sigprocmask(单线程/主线程初始设置) 或 pthread_sigmask(多线程/任何线程) 的 SIG_BLOCK操作（或 SIG_SETMASK），将新构建的信号集应用到当前线程的屏蔽字中。强烈建议保存旧屏蔽字 (oldset)。
执行受保护代码： 在阻塞状态下执行你不希望被特定信号中断的代码。
恢复屏蔽字： 使用 sigprocmask或 pthread_sigmask的 SIG_SETMASK操作，将屏蔽字恢复为之前保存的旧值 (oldset)。这一步隐含着解除对之前阻塞信号的阻塞，并可能触发之前未决信号的递达。

执行代码，观察现象

在前面的代码中，我们已经尝试过正常的阻塞信号了，接下来我们写代码来验证一些别的事情：

我们都知道，信号递达的时候，进程中的pending位图中相应的位置要被置为0。

结论1：那么是先将进程中的pending位图中相应的位置置为0，再递达处理？

结论2：还是先递达处理，再将进程中的pending位图中相应的位置置为0？

#include <iostream>#include <signal.h>#include <unistd.h>#include <cassert>#include <sys/wait.h>// 打印未决信号集void PrintSig(sigset_t &pending){std::cout << "Pending bitmap: ";// 虽然我们没办法直接打印未决信号集// 但是我们可以借助sigismember函数,判断未决信号集中是否有相应的信号// 如果有就打印1// 没有就打印0for (int signo = 31; signo > 0; signo--){if (sigismember(&pending, signo)){std::cout << "1";}else{std::cout << "0";}}std::cout << std::endl;}void handler(int signo){sigset_t pending;sigemptyset(&pending);int n = sigpending(&pending); // 我正在处理2号信号！！assert(n == 0);// 3. 打印pending位图中的收到的信号std::cout << "递达中...: ";PrintSig(pending); // 0: 递达之前，pending 2号已经被清0. 1: pending 2号被清0一定是递达之后std::cout << signo << " 号信号被递达处理..." << std::endl;}int main(){// 对2号信号进行自定义捕捉 --- 不让进程因为2号信号而终止signal(2, handler);// 1. 屏蔽2号信号// 声明两个新的信号集,block用来设置要屏蔽的信号,oblock用来保存旧的信号集sigset_t block, oblock;// 对两个信号集进行初始化sigemptyset(&block);sigemptyset(&oblock);// 添加要阻塞的信号// 注意: 这里根本就没有设置进当前进程的PCB blocked位图中// 这里只是添加到了我们创建的block信号集里sigaddset(&block, 2);// 1.1 开始屏蔽2号信号，其实就是设置进入内核中int n = sigprocmask(SIG_SETMASK, &block, &oblock);assert(n == 0);// 判断是否执行成功// 打印信息std::cout << "block 2 signal success" << std::endl;std::cout << "pid: " << getpid() << std::endl;int cnt = 0;while (true){// 2. 获取进程的pending位图// 也就是获取现在有多少未决信号// 同样是先声明新的信号集sigset_t pending;// 初始化sigemptyset(&pending);// 获取未决信号集n = sigpending(&pending);assert(n == 0);// 判断是否执行成功// 3. 打印pending位图中的收到的信号PrintSig(pending);cnt++;// 4. 解除对2号信号的屏蔽if (cnt == 20){std::cout << "解除对2号信号的屏蔽" << std::endl;n = sigprocmask(SIG_UNBLOCK, &block, &oblock); // 2号信号会被立即递达, 默认处理是终止进程assert(n == 0);}sleep(1);}return 0;}

这里我再给大家简单介绍有一下这个代码的思路：（我们以2号信号为例）

我们的思路是在信号递达处理函数中打印出未决信号集的情况，来判断前面问题中提到的先后。如果在递达处理函数中打印出来的未决信号集中2号信号的标志位已经被置0，则是结论1。反之就是结论2。

所以我们得自定义进程对2号信号的处理函数。让信号递达的时候，打印未决信号集的详情。

因为只有当信号被进程阻塞（屏蔽）的时候，信号才会被放入未决信号集。（如果没有阻塞信号，内核会倾向于立刻处理这个信号，导致我们无法看到未决信号集的一个变化情况）

所以我们得先阻塞2号信号。阻塞成功后打印信息来提醒我们情况，其中最主要的是进程PID，因为我们自定义了进程对2号信号的处理函数，所以我们得使用别的信号来终止进程。

紧接着就进入到循环中，我们每隔一秒打印一次未决信号集的情况，一共打印20次，也就是20秒，在这20秒时间中，我们要给进程发送2号信号，这样未决信号集中的2号信号标志位才会被置为1。

当打印了20次未决信号集后，我们就解除进程对2号信号的阻塞，进程执行自定义的处理函数，打印并观察未决信号集，发现：

未决信号集在递达处理过程中就已经被处理了，也就是说：进程中的pending位图中相应的位置已经被置为0了。

所以由此我们就可以得出在标准信号中：是先将进程中的pending位图中相应的位置置为0，再递达处理。

在这里插入图片描述

在 Linux 内核中，信号递达时 pending 位图的清零时机取决于信号的类型（标准信号 vs 实时信号）以及信号处理程序是否需要 siginfo_t信息。让我们分情况详细说明：

核心原则：状态一致性

内核的核心目标是维护信号状态的一致性。在信号被真正处理（递达）之前，它必须被标记为“正在处理中”，以防止在处理过程中产生歧义（例如，同一个信号实例被处理两次）。

情况 1：标准信号 (Signals 1-31) - 非队列化，通常不需要 siginfo

检查 pending： 内核决定递达一个标准信号 sig。
清除 pending 位图：首先，内核会立即清除该线程的 pending.signal位图中对应于 sig的位（将其置为 0）。这是关键一步！
- 为什么先清除？ 因为标准信号是非队列化的。pending.signal位图中的置位仅表示“至少有一个 sig信号待处理”。清除它表示“这个待处理的信号实例现在被认领处理了”。即使后续在信号处理程序执行期间或之前又有新的 sig信号产生，它们会被视为新的待处理实例（可能再次置位 pending 位图，也可能被丢弃，取决于信号类型和产生时机）。
准备递达： 内核根据 sighand->action[sig]的设置准备执行动作（默认、忽略、捕获）。
执行递达动作：
- 忽略 (SIG_IGN)： 内核不做其他操作（pending 位图在第 2 步已清除）。
- 默认动作： 内核执行默认操作（如终止进程）。pending 位图状态已无关紧要。
- 捕获动作 (用户处理程序)：
  - 内核会临时修改线程的 blocked掩码（通常阻塞 sig本身和 action[sig].sa.mask中指定的信号），并将旧的 blocked掩码保存到 real_blocked。
  - 内核设置用户栈帧，准备调用用户注册的信号处理函数 handler。
  - 控制权转移到用户空间的 handler函数执行。
  - 用户处理函数执行完毕（或调用 longjmp/exit等）。
  - 如果处理函数正常返回，内核通过 sigreturn系统调用恢复原始的 blocked掩码（从 real_blocked恢复）。

总结 (标准信号)：先清除 pending 位图，再执行递达动作。

情况 2：实时信号 (Signals 34-64) 或需要 SA_SIGINFO的标准信号 - 队列化，携带 siginfo

检查 pending： 内核决定递达一个信号 sig（实时信号或设置了 SA_SIGINFO的标准信号）。
获取 sigqueue 结构： 内核从该线程的 pending.list链表中取出一个代表该信号实例的 struct sigqueue节点。
更新 pending 状态：
- 内核检查 pending.list链表中是否还有其他属于信号 sig的 sigqueue节点。
- 如果没有其他 sig节点了： 内核清除 pending.signal位图中对应于 sig的位（置 0）。这表示该信号类型暂时没有未决实例了。
- 如果还有其他 sig节点：pending.signal位图中 sig对应的位保持置位 (1)，表示仍有同类型信号在排队等待。
准备递达： 内核提取 sigqueue->info中的 siginfo_t信息。
执行递达动作：
- 忽略 (SIG_IGN)： 内核释放取出的 sigqueue结构（pending 状态已在第 3 步更新）。
- 默认动作： 内核执行默认操作并释放 sigqueue。
- 捕获动作 (用户处理程序)：
  - 内核临时修改 blocked掩码（保存到 real_blocked）。
  - 内核设置用户栈帧，并将 siginfo_t信息（以及可能的 ucontext）传递给用户注册的处理函数（sa_sigaction或三参数的 sa_handler）。
  - 控制权转移到用户空间的信号处理函数执行。
  - 用户处理函数执行完毕。
  - 内核通过 sigreturn恢复原始的 blocked掩码。
  - 内核释放取出的 sigqueue结构。

总结 (实时信号/SA_SIGINFO)：

先从 pending.list取出一个 sigqueue节点（代表一个具体的信号实例）。
然后根据队列中是否还有同类型信号，更新 pending.signal位图（可能清零，也可能保持置位）。
最后执行递达动作（包括调用用户处理程序）并释放 sigqueue结构。

为什么这样设计？

状态原子性： 对于标准信号，先清除 pending 位图确保了“认领”该信号实例的原子性。一旦清除，即使新信号立刻产生，也被视为新事件。
队列化管理： 对于实时信号，pending.signal位图指示的是“该信号类型是否有未决实例”，而不是实例数量。取出一个节点后，需要检查队列是否为空来决定是否清除位图。位图的存在是为了让内核快速判断是否有某类信号待处理，而不必遍历链表。
siginfo_t的生命周期：siginfo_t信息存储在 sigqueue结构中。内核必须在确保该信息被安全传递（或决定丢弃）之后，才能释放 sigqueue。在用户处理程序执行期间，siginfo_t是有效的（位于用户栈或寄存器中）。
避免重复处理： 清除 pending 状态（位图或取出节点）的操作发生在实际执行处理动作之前，这严格保证了同一个信号实例不会被递达两次。

结论：

标准信号 (非 SA_SIGINFO)：先清除 pending.signal位图中的对应位，再执行递达动作。
实时信号或设置了 SA_SIGINFO的标准信号：
- 先从 pending.list取出代表该信号实例的 sigqueue节点。
- 然后根据队列情况更新 pending.signal位图（可能清零对应位）。
- 最后执行递达动作（传递 siginfo_t）并释放 sigqueue结构。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/963787.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

深入解析：SQL提数与数据分析指南

深入解析：SQL提数与数据分析指南pre { white-space: pre !important; word-wrap: normal !important; overflow-x: auto !important; display: block !important; font-family: "Consolas", "Monaco&q…