Linux 信号保存机制深度解析：从内核数据结构到进程状态管理

喜欢吃燃面2026-04-27 10:55

目录

  • 引言
  • 一、为什么信号需要保存？
    • [1. 异步性与时间窗口](#1. 异步性与时间窗口)
    • [2. 信号的生命周期](#2. 信号的生命周期)
  • 二、信号保存的核心数据结构
    • [1. sigset_t：信号的位图表示](#1. sigset_t：信号的位图表示)
    • [2. 进程控制块中的信号相关字段](#2. 进程控制块中的信号相关字段)
    • [3. 标准信号与实时信号的保存差异](#3. 标准信号与实时信号的保存差异)
  • 三、信号阻塞与未决状态的管理
    • [1. 信号阻塞（Blocking）机制](#1. 信号阻塞（Blocking）机制)
    • [2. 未决信号（Pending）的维护](#2. 未决信号（Pending）的维护)
    • [3. 信号掩码的继承与恢复](#3. 信号掩码的继承与恢复)
  • 四、信号保存的内核路径分析
    • [1. 信号产生的内核路径](#1. 信号产生的内核路径)
    • [2. 信号交付的时机与条件](#2. 信号交付的时机与条件)
    • [3. 信号处理的上下文切换](#3. 信号处理的上下文切换)
  • 五、信号保存的边界情况与高级特性
    • [1. 信号队列溢出与资源限制](#1. 信号队列溢出与资源限制)
    • [2. 多线程环境中的信号保存](#2. 多线程环境中的信号保存)
    • [3. 信号的可靠保存与不可靠信号](#3. 信号的可靠保存与不可靠信号)
    • [4. 信号与系统调用的重启](#4. 信号与系统调用的重启)
  • 六、信号保存机制的实际影响与编程实践
    • [1. 信号丢失与合并的编程考虑](#1. 信号丢失与合并的编程考虑)
    • [2. 原子性信号操作](#2. 原子性信号操作)
    • [3. 信号文件描述符（signalfd）](#3. 信号文件描述符（signalfd）)
  • 七、信号保存机制的演进与未来
    • [1. 从早期 Unix 到现代 Linux](#1. 从早期 Unix 到现代 Linux)
    • [2. 与其他操作系统机制的对比](#2. 与其他操作系统机制的对比)
  • 结语

哈喽，编程搭子们！😜 又到了沉浸式敲代码的快乐时间～把生活调成「代码模式」，带着满满的热爱钻进编程的奇妙世界------今天也要敲出超酷的代码，冲鸭！🚀

✨ 我的博客主页：喜欢吃燃面
📚 我的专栏（持续更新ing）：
《C语言》 |
《C语言之数据结构》 |
《C++》 |
《Linux学习笔记》

💖 超感谢你点开这篇博客！真心希望这些内容能帮到正在打怪升级的你～如果有任何想法、疑问，或者想交流学习心得，都欢迎留言/私信，咱们一起在编程路上互相陪伴、共同进步呀！

引言

在 Linux 操作系统中，信号（Signal）是一种异步通知机制，用于通知进程发生了某个特定事件。与同步的函数调用不同，信号的产生和处理存在时间差------信号可能在任何时刻产生，但进程并非立即处理。这种异步特性决定了信号必须被"保存"起来，等待合适的时机交付给进程处理。本文将深入探讨 Linux 内核中信号的保存机制，从位图数据结构到进程状态转换，全面解析这一核心操作系统概念。

一、为什么信号需要保存？

1. 异步性与时间窗口

信号的本质是异步的。当硬件异常（如除零错误）、软件条件（如定时器到期）或外部事件（如用户按下 Ctrl+C）发生时，内核需要通知目标进程。然而，进程可能正处于关键代码段、系统调用中，或者信号处理函数尚未注册。这就产生了一个核心问题：信号产生后不能立即处理，必须有一个保存机制来 bridging the gap。

信号从产生到处理之间存在一个时间窗口。在这个窗口期内，信号必须被可靠地保存，确保不会丢失，同时也要支持多个相同信号的叠加处理。这种保存需求催生了内核中精巧的数据结构设计。

2. 信号的生命周期

一个完整的信号生命周期包含三个关键阶段：
硬件异常/软件条件/外部事件
内核检测到事件\n保存到未决队列
进程适合处理信号\n(系统调用返回/中断返回)
执行handler/默认动作/忽略
信号被阻塞\n继续保存在pending队列
信号被忽略且未注册handler\n(某些条件下)
产生
等待
交付
处理完成
丢弃

产生（Generation）：内核检测到事件，决定向某个进程或进程组发送信号。此时信号进入"已生成"状态。

等待（Pending）：信号已产生但尚未交付给进程。这是信号保存的核心阶段，信号被存储在内核数据结构中，等待处理时机。

交付（Delivery）：内核将信号传递给进程，触发相应的处理动作（执行默认操作、忽略或调用用户注册的处理函数）。

在这三个阶段中，"等待"阶段是信号保存机制发挥作用的关键。如果信号在产生后不能被妥善保存，就会导致信号丢失，这是操作系统设计中不可接受的。

二、信号保存的核心数据结构

1. sigset_t：信号的位图表示

Linux 内核使用位图（Bitmap）来高效地表示信号集合。sigset_t 是这一机制的核心数据结构，本质上是一个位数组，每一位对应一个特定的信号编号。
sigset_t 位图结构 (128位/16字节)
bit 0

SIGUNUSED
bit 1

SIGHUP
bit 2

SIGINT
bit 3

SIGQUIT
bit 4

SIGILL
bit 5

SIGTRAP
bit 6

SIGABRT
bit 7

SIGBUS
bit 8

SIGFPE
bit 9

SIGKILL
bit 10

SIGUSR1
bit 11

SIGSEGV
bit 12

SIGUSR2
bit 13

SIGPIPE
bit 14

SIGALRM
bit 15

SIGTERM

在 64 位系统上，unsigned long 为 64 位，_SIGSET_NWORDS 通常为 16，可以表示 1024 个信号位。虽然 Linux 目前只定义了 64 个标准信号（1-31 为传统信号，32-64 为实时信号），但位图设计预留了扩展空间。

这种位图设计的优势在于：

  • 空间效率：用 1024 位即可表示 1024 个信号的状态，而非使用 1024 个字节或更大的结构体
  • 操作效率：信号的添加、删除、检查都可以通过位运算（OR、AND、NOT）在常数时间内完成
  • 批量操作 ：可以一次性操作整个信号集合，如 sigorset、sigandset 等

2. 进程控制块中的信号相关字段

每个进程的内核表示（task_struct）中包含多个与信号保存相关的关键字段：
线程组共享
共享处理动作
私有未决信号
共享未决信号
实时信号队列
1
1
1
1
1
1
1
1
1
*
task_struct
+struct signal_struct* signal
+struct sighand_struct* sighand
+sigset_t blocked
+sigset_t real_blocked
+struct sigpending pending
+...其他字段...
signal_struct
+struct sigpending shared_pending
+struct rlimit rlim[_RLIM_NLIMITS]
+...其他字段...
sighand_struct
+struct k_sigaction action[_NSIG]
+spinlock_t siglock
sigpending
+struct list_head list
+sigset_t signal
sigqueue
+struct list_head list
+int flags
+siginfo_t info
+struct user_struct* user

c 复制代码 
struct task_struct {
    // ... 其他字段 ...
    
    /* 信号处理 */
    struct signal_struct *signal;      // 共享的信号信息（线程组共享）
    struct sighand_struct *sighand;    // 信号处理动作表
    
    /* 信号阻塞与未决状态 */
    sigset_t blocked;                  // 进程阻塞的信号集合
    sigset_t real_blocked;             // 用于保存之前的阻塞状态（如信号处理期间）
    
    /* 未决信号（私有） */
    struct sigpending pending;         // 进程私有的未决信号队列
    
    // ... 其他字段 ...
};

struct signal_struct {
    // 线程组共享的未决信号
    struct sigpending shared_pending;  // 共享的未决信号（发送给进程组的信号）
    
    // 信号处理相关计数器和限制
    struct rlimit rlim[_RLIM_NLIMITS];
    // ...
};

struct sigpending {
    struct list_head list;             // 挂起的信号链表（用于实时信号）
    sigset_t signal;                   // 挂起信号的位图（用于标准信号）
};

这里的关键设计是分层保存：

  • blocked 位图：记录进程主动阻塞的信号
  • pending.signal 位图：记录已产生但未处理的信号
  • pending.list 链表：为实时信号提供队列支持（因为实时信号支持排队，多个相同实时信号可以同时挂起）

3. 标准信号与实时信号的保存差异

Linux 信号分为两类，它们的保存机制有本质区别：
实时信号 (32-64)
SIGRTMIN ~ SIGRTMAX
位图 + 链表保存
每个实例独立记录
支持FIFO排队
可携带siginfo_t数据
严格按顺序处理
标准信号 (1-31)
SIGINT, SIGTERM, SIGKILL等
位图保存
仅记录是否未决
不支持排队
多次发送合并为1次
处理函数至少执行一次

标准信号（1-31）：

  • 使用位图保存，每个信号只有"未决"或"非未决"两种状态
  • 不支持排队：如果同一个标准信号多次产生而未被处理，只保留一个未决状态
  • 例如：如果 SIGINT（信号 2）被发送三次，但进程尚未处理，pending 位图中第 2 位仍为 1，而非 3

实时信号（32-64）：

  • 使用位图 + 链表的双重机制保存
  • 支持排队 ：每个实时信号实例都被分配一个 sigqueue 结构，通过链表链接
  • 可以携带附加数据（通过 sigqueue 结构的 info 字段）
  • 遵循 FIFO 处理顺序
c 复制代码 
struct sigqueue {
    struct list_head list;             // 链表指针
    int flags;                         // 标志位
    siginfo_t info;                    // 信号详细信息（包含发送者 PID、UID、信号值等）
    struct user_struct *user;          // 指向发送者用户结构（用于资源计费）
};

这种差异化设计反映了两种信号的使用场景：标准信号用于异步事件通知（不需要保留多次触发的历史），实时信号用于需要可靠传递和排队语义的 IPC 场景。

三、信号阻塞与未决状态的管理

1. 信号阻塞（Blocking）机制

信号阻塞是信号保存机制的重要组成部分。进程可以通过 sigprocmask() 系统调用（或 pthread_sigmask()）显式阻塞某些信号。被阻塞的信号即使产生，也不会立即交付给进程，而是保存在未决状态，直到解除阻塞。
后续处理
处理路径
阻塞检查
信号到达内核
否
是
信号产生
信号是否在

blocked集合?
立即尝试交付
保存到pending队列
系统调用返回时处理
解除阻塞后处理

阻塞的实现原理 ：

内核维护 blocked 位图，当信号产生时，内核首先检查该信号是否在 blocked 集合中：

  • 如果未阻塞：立即尝试交付（如果进程处于可中断状态）或保存到未决队列
  • 如果已阻塞：直接保存到未决队列，等待后续解除阻塞时处理
c 复制代码 
// 简化的信号检查逻辑
int sigismember(const sigset_t *set, int sig) {
    // 检查位图中对应信号位是否为 1
    unsigned long word = sig / (8 * sizeof(unsigned long));
    unsigned long mask = 1UL << (sig % (8 * sizeof(unsigned long)));
    return (set->__val[word] & mask) != 0;
}

2. 未决信号（Pending）的维护

未决信号是"已产生但尚未处理"的信号集合。内核通过以下方式维护未决状态：
用户进程 进程控制块 内核 事件源 用户进程 进程控制块 内核 事件源 alt [标准信号] [实时信号] 系统调用返回/中断返回时 alt [标准信号] [实时信号] 产生信号 (如SIGINT) 确定目标进程 检查信号是否被忽略 设置 pending.signal 对应位 设置 TIF_SIGPENDING 标志 分配 sigqueue 结构 加入 pending.list 链表 设置 pending.signal 对应位 设置 TIF_SIGPENDING 标志 signal_wake_up() 唤醒进程 检查 TIF_SIGPENDING 读取 pending 队列 调用 do_signal() 处理 清除 pending.signal 对应位 从 list 移除 sigqueue 如链表空则清除位图 交付信号 (执行handler)

产生信号时的保存逻辑：

  1. 内核确定目标进程/线程组
  2. 检查信号是否被忽略（SIG_IGN）或默认处理为忽略
  3. 如果信号被阻塞，或进程当前不适合立即处理（如正在执行关键路径），将信号加入未决集合：
    • 标准信号：设置 pending.signal 对应位
    • 实时信号：分配 sigqueue 结构，加入 pending.list 链表，同时设置位图
  4. 设置进程状态，标记有待处理信号（TIF_SIGPENDING 线程标志）

未决信号的清理 ：

当信号成功交付后，内核从 pending 中移除该信号：

  • 标准信号：清除对应位图位
  • 实时信号：从链表中移除对应节点，如果链表为空则清除位图位

3. 信号掩码的继承与恢复

信号阻塞掩码在进程生命周期中有复杂的继承规则：
信号处理期间
进入 handler
自动阻塞当前信号
可选阻塞 sa_mask 信号
执行用户 handler
sigreturn 恢复旧掩码
恢复之前上下文
exec() 保留
当前 blocked 掩码
新程序保留 blocked
信号处理动作重置为默认
sighand 重新初始化
fork() 继承
父进程 blocked 掩码
子进程继承 blocked
子进程清空 pending 队列
子进程不继承未决信号

fork() 继承：子进程继承父进程的信号阻塞掩码，但清空未决信号队列（子进程不应继承父进程的异步事件）

exec() 保留：执行新程序时，信号阻塞掩码保持不变（程序可能依赖特定的信号屏蔽设置），但信号处理动作重置为默认（因为新程序的代码段已改变）

信号处理期间的自动阻塞 ：

当进程执行信号处理函数时，内核会自动阻塞该信号（防止递归处理），并可选择性地阻塞 sa_mask 中指定的其他信号。处理完成后，内核恢复之前的阻塞状态：

c 复制代码 
// 信号处理时的栈帧结构（简化）
struct sigframe {
    // 保存的上下文
    sigset_t old_blocked;              // 保存旧的阻塞掩码
    struct sigcontext sc;              // 保存的寄存器状态
    // ...
};

这种自动保存/恢复机制确保了信号处理的原子性和可重入安全性。

四、信号保存的内核路径分析

1. 信号产生的内核路径

信号可以通过多种途径产生，每种途径最终都会调用 send_signal() 或类似函数将信号加入目标进程的未决队列：
软件事件
系统调用
终端输入
硬件异常
除零错误
CPU 异常
段错误
非法指令
force_sig_info()
Ctrl+C
TTY 驱动 isig()
Ctrl+Z
kill_pgrp()
kill()
sys_kill()
sigqueue()
sys_rt_sigqueueinfo()
pthread_kill()
tkill()
定时器到期
do_timer()
子进程状态变更
do_notify_parent()
管道写端关闭
send_sigpipe()
__send_signal()
保存到 pending 队列
signal_wake_up()

1. 硬件异常 （如除零、段错误）：

CPU 产生异常 → 内核异常处理程序 → force_sig_info() → 设置未决信号

2. 终端输入 （如 Ctrl+C）：

TTY 驱动检测到控制字符 → isig() → kill_pgrp() → 向进程组发送信号

3. 系统调用 （如 kill(), sigqueue()）：

用户空间调用 → sys_kill() / sys_rt_sigqueueinfo() → kill_something_info() → 遍历目标进程

4. 软件事件 （如定时器到期、子进程状态变更）：

内核定时器到期 → do_timer() → send_group_signal() 或 send_signal()

所有这些路径最终汇聚到 __send_signal() 函数，这是信号保存的核心实现：

c 复制代码 
static int __send_signal(int sig, struct kernel_siginfo *info, 
                         struct task_struct *t, enum pid_type type, bool force)
{
    struct sigpending *pending;
    struct sigqueue *q;
    
    // 确定使用私有队列还是共享队列
    pending = (type != PIDTYPE_PID) ? &t->signal->shared_pending : &t->pending;
    
    // 检查信号是否已存在（标准信号不排队）
    if (legacy_queue(pending, sig))
        return 0;  // 标准信号已存在，直接返回（不重复保存）
    
    // 为实时信号分配队列节点
    if (sig < SIGRTMIN) {
        // 标准信号：仅设置位图
        set_bit(sig - 1, pending->signal.sig);
    } else {
        // 实时信号：分配 sigqueue 并加入链表
        q = __sigqueue_alloc(sig, t, GFP_ATOMIC);
        if (!q)
            return -ENOMEM;  // 达到排队限制
        copy_siginfo(&q->info, info);
        list_add_tail(&q->list, &pending->list);
        set_bit(sig - 1, pending->signal.sig);
    }
    
    // 标记进程有待处理信号
    signal_wake_up(t, type == PIDTYPE_PID);
    
    return 0;
}

2. 信号交付的时机与条件

信号并非保存在未决队列后就立即交付。内核在以下时机检查并处理未决信号：
处理条件
信号未被阻塞
进程处于合适状态
有注册的处理函数或默认动作
信号交付时机
系统调用返回
do_signal()

检查TIF_SIGPENDING
中断返回
检查信号状态
从可中断睡眠唤醒
返回-EINTR或处理信号
显式检查点
signal_pending()
执行信号处理

1. 从系统调用返回时 ：

这是最常见的信号交付时机。当进程执行完系统调用准备返回用户空间时，内核检查 TIF_SIGPENDING 标志。如果存在未决信号且未被阻塞，内核调用 do_signal() 进行信号处理。

2. 从中断返回时 ：

类似于系统调用返回，硬件中断处理完成后，内核会检查信号状态。

3. 进程从睡眠状态唤醒时 ：

如果进程因等待资源而睡眠（可中断睡眠状态 TASK_INTERRUPTIBLE），当资源可用时，内核会检查是否有信号待处理。如果有，系统调用可能返回 -EINTR（被中断），并将信号保存到未决队列。

4. 显式检查点 ：

某些代码路径会显式调用 signal_pending() 检查是否有信号需要处理。

3. 信号处理的上下文切换

信号处理涉及复杂的上下文切换，因为处理函数在用户空间执行，而信号检测在内核空间：
信号处理函数 用户栈 内核空间 用户空间代码 信号处理函数 用户栈 内核空间 用户空间代码 构建信号帧 sigframe 系统调用/中断 检查 TIF_SIGPENDING get_signal() 获取未决信号 保存寄存器状态 (sigcontext) 保存旧信号掩码 (old_blocked) 设置返回地址为 handler 设置 sigreturn 系统调用地址 返回到 handler 入口 执行信号处理函数 sigreturn() 系统调用 恢复寄存器状态 恢复旧信号掩码 清除已处理信号的 pending 状态 返回到原代码继续执行

c 复制代码 
// 简化的信号处理流程
void do_signal(struct pt_regs *regs) {
    struct ksignal ksig;
    
    // 从 pending 队列中取出一个可处理的信号
    if (!get_signal(&ksig))
        return;  // 没有可处理的信号
    
    // 设置信号处理函数的调用帧
    handle_signal(&ksig, regs);
    
    // 如果信号处理函数使用 sigaction 的 SA_ONESHOT 标志，重置处理动作为默认
    // ...
}

handle_signal() 需要：

  1. 在用户栈上创建信号帧（sigframe），保存当前寄存器状态和信号掩码
  2. 修改返回地址，使进程从系统调用返回时进入信号处理函数而非原代码
  3. 如果需要，设置备用信号栈（sigaltstack）

处理完成后，通过 sigreturn() 系统调用恢复之前的上下文：

  1. 从信号帧中恢复寄存器状态
  2. 恢复之前的信号阻塞掩码
  3. 清除该信号的未决状态（如果是实时信号，从链表中移除）

五、信号保存的边界情况与高级特性

1. 信号队列溢出与资源限制

实时信号的排队能力并非无限。内核通过 RLIMIT_SIGPENDING 限制每个用户可以排队的实时信号总数。当达到限制时，新的实时信号产生会失败（sigqueue() 返回 -1，errno 设为 EAGAIN）。
计数机制
每用户结构 user_struct
sigpending 计数器
分配时 +1
处理完成时 -1
RLIMIT_SIGPENDING 资源限制
是
否
实时信号到达
用户信号数 < limit?
分配 sigqueue
加入 pending 队列
返回 -EAGAIN
信号丢失

这种限制防止了恶意进程或程序错误导致的内存耗尽。标准信号不受此限制，因为它们不分配额外内存。

2. 多线程环境中的信号保存

在多线程程序中，信号保存机制更加复杂：
线程独立掩码
线程 t1 blocked
各自独立设置
线程 t2 blocked
线程 t3 blocked
进程共享信号 (kill)
进程组信号
保存到 signal->shared_pending
选择处理线程
不阻塞该信号的线程
优先级合适的线程
通过 signal_wake_up 唤醒
线程私有信号 (pthread_kill)
目标线程 t1
保存到 t1->pending
仅 t1 可处理

线程私有与共享信号：

  • 发送给特定线程的信号（pthread_kill()）：保存在目标线程的 t->pending 中
  • 发送给进程的信号（kill()）：保存在共享的 signal->shared_pending 中，由线程组中的任意线程处理

线程的信号掩码独立性 ：

每个线程有独立的 blocked 掩码（通过 pthread_sigmask() 设置），但共享信号处理动作表（sighand）。

信号处理的线程选择 ：

当共享信号到达时，内核选择哪个线程来处理？规则是：

  1. 选择不阻塞该信号的线程
  2. 如果有多个，选择当前未运行或优先级合适的线程
  3. 通过 signal_wake_up() 唤醒目标线程

3. 信号的可靠保存与不可靠信号

早期 Unix 信号机制存在"不可靠信号"问题：信号在处理前可能丢失。Linux 通过以下改进解决了这一问题：
早期Unix V7 信号处理重置为默认 不可靠 无阻塞机制 信号易丢失 内核态不保存 高丢失率 BSD 4.2 引入可靠信号 处理动作持久化 信号阻塞雏形 初步保存能力 POSIX.1 sigaction() 完整保存语义 信号集操作 批量管理 实时信号扩展 排队支持 现代Linux 完全可靠保存 所有信号持久化 实时信号队列 FIFO + 数据携带 signalfd/pidfd 统一事件抽象 信号机制演进

可靠保存：所有产生的信号都被保存到未决队列，不会无故丢失（只要内存足够）。

标准信号的合并：虽然标准信号不排队，但内核保证至少保留一个未决实例。如果同一个标准信号在短时间内多次产生，处理函数至少会被调用一次。

实时信号的完全排队：实时信号保证严格排队，每个实例都被独立保存和处理，支持传递附加数据。

4. 信号与系统调用的重启

某些慢速系统调用（如 read(), write(), accept()）可能被信号中断。内核提供了自动重启机制：
用户空间处理
SA_RESTART 检查
系统调用被信号中断
是
否
慢速系统调用执行中
信号到达
设置返回 -EINTR
sa_flags & SA_RESTART?
自动重启系统调用
返回 -EINTR 给用户
检查 errno == EINTR
决定是否手动重试

c 复制代码 
// 信号处理时检查 SA_RESTART 标志
if (ksig.ka.sa.sa_flags & SA_RESTART) {
    // 设置返回值为 -EINTR，但用户库可能自动重试
    // 或者内核直接重启系统调用（取决于架构和具体调用）
}

当信号处理函数返回时，如果系统调用设置了 SA_RESTART 标志，内核可以自动重新执行被中断的系统调用，而非返回 -EINTR 错误。这一机制对保存的信号处理尤为重要，因为它确保了信号处理不会破坏正常的 I/O 语义。

六、信号保存机制的实际影响与编程实践

1. 信号丢失与合并的编程考虑

由于标准信号不排队，编程时必须考虑信号合并的情况：
✅ 方案2：事件聚合
使用 signalfd()
或使用 self-pipe 技巧
将信号转为 I/O 事件
通过 epoll 统一处理
✅ 方案1：实时信号
使用 SIGRTMIN+0
支持排队，每次都有独立实例
通过 siginfo_t 传递数据
❌ 错误做法：依赖信号计数
volatile int count = 0
SIGUSR1 产生
handler: count++
SIGUSR1 再次产生
handler未执行
信号合并，count只增1
计数不准确

c 复制代码 
// 错误示例：依赖信号计数
volatile int sigusr1_count = 0;

void handler(int sig) {
    sigusr1_count++;  // 不可靠！多个 SIGUSR1 可能合并为一个
}

// 正确做法：使用实时信号或管道事件通知
// 方案 1：使用 SIGRTMIN+0 替代 SIGUSR1（支持排队）
// 方案 2：使用 signalfd() 或 self-pipe 技巧进行事件聚合

2. 原子性信号操作

sigprocmask() 和相关函数提供原子性的信号阻塞操作，这对临界区保护至关重要：
原子性恢复
临界区执行
原子性阻塞信号
sigemptyset(&new)
sigaddset(&new, SIGINT)
sigaddset(&new, SIGTERM)
sigprocmask(SIG_BLOCK, &new, &old)
敏感代码段
保证不被SIGINT/SIGTERM中断
sigprocmask(SIG_SETMASK, &old, NULL)

c 复制代码 
sigset_t new_mask, old_mask;

// 原子性地阻塞 SIGINT 和 SIGTERM，保存旧掩码
sigemptyset(&new_mask);
sigaddset(&new_mask, SIGINT);
sigaddset(&new_mask, SIGTERM);
sigprocmask(SIG_BLOCK, &new_mask, &old_mask);

// 临界区：保证不被 SIGINT 或 SIGTERM 中断
// ...

// 原子性恢复之前的信号掩码
sigprocmask(SIG_SETMASK, &old_mask, NULL);

这种原子性操作确保了信号保存状态的一致性，避免了竞态条件。

3. 信号文件描述符（signalfd）

Linux 特有的 signalfd() 机制提供了信号保存的另一种视角：
signalfd 方式
信号到达
保存到 fd 缓冲区
epoll_wait/select 唤醒
read(fd) 读取信号信息
在用户态处理信号
无需上下文切换
传统信号处理
信号到达
中断当前执行
保存上下文
执行 handler
恢复上下文
继续执行

c 复制代码 
int sfd = signalfd(-1, &mask, SFD_NONBLOCK | SFD_CLOEXEC);
// 将信号转换为文件描述符上的可读事件
// 可以使用 epoll/select/poll 统一处理信号和 I/O

signalfd 将信号保存到文件描述符的内核缓冲区，允许通过标准 I/O 多路复用机制处理信号。这实际上是信号保存机制的一种抽象和扩展。

七、信号保存机制的演进与未来

1. 从早期 Unix 到现代 Linux

信号保存机制经历了显著演进：
1979 Unix V7 信号处理重置 每次处理后恢复默认 无保存机制 信号极易丢失 不可靠信号 内核不保证交付 1983 BSD 4.2 可靠信号扩展 处理动作持久化 信号阻塞引入 初步保存能力 sigblock/sigsetmask 掩码操作 1990 POSIX.1 sigaction() 标准化接口 信号集数据类型 sigset_t 实时信号扩展 SIGRTMIN-SIGRTMAX 1996 POSIX.1b 实时信号排队 sigqueue() 信号携带数据 siginfo_t 优先级继承 严格的FIFO顺序 2007 Linux 2.6.22 signalfd() 文件描述符抽象 统一事件处理 与epoll集成 2019 Linux 5.1 pidfd_send_signal() 避免PID重用 pidfd 机制 更安全的信号发送 io_uring 融合 异步信号处理 信号保存机制演进史

早期 Unix（V7, BSD4.2）：

  • 信号处理动作在处理后重置为默认（不可靠）
  • 无信号阻塞机制
  • 信号可能在内核态丢失

POSIX 实时扩展：

  • 引入 sigaction()，支持信号处理动作的持久化
  • 引入信号集和信号阻塞机制
  • 引入实时信号排队

Linux 现代化改进：

  • signalfd, timerfd, eventfd 统一事件处理
  • pidfd_send_signal() 提供基于文件描述符的信号发送（避免 PID 重用竞争）
  • 更精细的 siginfo_t 信息传递

2. 与其他操作系统机制的对比

现代异步 I/O
io_uring 共享环缓冲区
零拷贝事件传递
减少系统调用开销
信号与 I/O 融合
BSD kqueue
统一事件通知框架
EVFILT_SIGNAL 过滤器
与文件/I/O事件统一
kevent() 系统调用
Windows APC
线程上下文排队
用户态/内核态 APC
强调线程亲和性
QueueUserAPC()
Linux 信号机制
位图 + 链表保存
标准信号合并
实时信号排队
signalfd 统一抽象

Windows APC（异步过程调用）：

  • 类似信号，但通常在线程上下文中排队执行
  • 更强调线程亲和性，而非进程级通知

BSD kqueue/EVFILT_SIGNAL：

  • 将信号事件集成到统一的事件通知框架
  • 类似于 Linux 的 signalfd，但更通用

现代异步 I/O 与 io_uring：

  • 信号机制与异步 I/O 的融合趋势
  • 通过共享环缓冲区减少系统调用开销

结语

Linux 的信号保存机制是操作系统异步事件处理的核心基础设施。从简单的位图到复杂的队列链表，从单进程到多线程环境，这一机制在保证效率的同时提供了灵活性和可靠性。理解信号的保存、阻塞、未决和交付全过程，对于编写健壮的系统级程序、调试复杂的并发问题以及深入理解操作系统内核原理都至关重要。
信号保存

核心要点
数据结构
sigset_t位图
sigpending队列
sigqueue链表
状态管理
blocked阻塞集
pending未决集
自动保存恢复
生命周期
产生
等待保存
交付处理
编程实践
原子操作
实时信号
signalfd

信号保存不仅仅是一个技术细节，它体现了操作系统设计中"异步事件管理"的通用哲学：如何在不可预测的事件产生时序与可控的处理逻辑之间建立可靠的桥梁。这种设计思想广泛应用于中断处理、消息队列、事件驱动编程等现代计算范式中，是理解计算机系统底层运作的关键窗口。

参考与延伸阅读：

  • Linux Kernel Source: kernel/signal.c, include/linux/signal.h, include/linux/sched.h
  • POSIX.1-2008 Standard: Signal Concepts (Base Definitions, Chapter 3.396)
  • 《Linux 内核设计与实现》（Robert Love）第 5 章：系统调用，第 10 章：进程调度
  • 《Unix 环境高级编程》（W. Richard Stevens）第 10 章：信号

希望这篇深入的技术博客能够帮助您全面理解 Linux 信号保存机制！如果您需要针对某个特定部分（如实时信号排队实现、多线程信号处理或 signalfd 内部机制）进行更深入的探讨，请告诉我。

相关推荐
hi_ro_a2 小时前
C++ 手撕 STL 底层：红黑树封装 mymap/myset
数据结构·c++·算法
求学的小高2 小时前
数据结构Day9（图的遍历、图应用及相关算法）
数据结构·笔记·考研
云边有个稻草人2 小时前
【Linux系统】第十节—【进程概念】环境变量 | 详解，包会！
linux·环境变量·命令行参数·环境变量的特性·获取linux环境变量的方法·环境变量path·通过代码获取linux环境变量
秋雨梧桐叶落莳2 小时前
iOS——Masonry约束内容整理
开发语言·学习·macos·ios·objective-c·cocoa
IMPYLH2 小时前
Linux 的 stdbuf 命令
linux·运维·服务器·bash
郝学胜-神的一滴2 小时前
从底层看透Linux高性能服务器：epoll自定义封装与超时清理实战
linux·服务器·c++·网络协议·tcp/ip·unix
Elastic 中国社区官方博客2 小时前
Elasticsearch 多年来的演进 —— LogsDB 如何在不影响吞吐量的情况下将索引大小减少高达 75%
大数据·运维·elasticsearch·搜索引擎·全文检索·可用性测试
keyipatience2 小时前
12.GDB调试技巧与计算机体系结构解析
linux·运维·服务器
小夏子_riotous2 小时前
Docker学习路径——9、Docker 网络深度解析：从默认网络到自定义网络实战
linux·运维·网络·docker·容器·centos·云计算
热门推荐
01GitHub 镜像站点02近期有什么ai的新消息，新动态？ 2026.4月032026年4月AI大事件深度解读：大模型竞争进入“深水区“042026年AI前瞻：量子AI、具身智能与科学发现的新纪元052026年4月技术前沿：AI大模型爆发、智能体革命与量子安全新纪元06codex app每次打开重连5次Reconnecting问题解决072026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot08AI Weekly | 2026年4月第二周 · GitHub热门项目与AI发展趋势深度解析09DeepSeek V4 全面解析：测评、对比、案例及实操指南10Codex 接入 DeepSeek API 完整配置文档