深入研究signal和sigaction

最新推荐文章于 2025-11-08 14:33:51 发布
原创 最新推荐文章于 2025-11-08 14:33:51 发布 · 1.8k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#signal #sigaction #内核

本文详细探讨了signal()和sigaction()在处理信号时的区别，指出signal()可能导致信号丢失的问题，而sigaction()通过信号屏蔽提供了更可靠的解决方案。通过分析Linux0.11内核源码，揭示了这两个函数的内部工作原理，帮助读者理解如何在内核中设置和管理信号处理。

信号通常使用一个无符号长整数(32位)中的比特位表示各种不同的信号。因此最多可以表示32个不同的信号。signal()和sigaction()的功能比较类似，都是更改信号原处理句柄(handler，或称为处理程序)。但signal()就是内核操作上述传统信号的方式，在某些特殊时刻可能会造成信号丢失。

之前介绍过signal()函数，signal()函数的返回值是一个无返回值且具有一个整型参数的函数指针,是默认的处理方式。并且在新句柄被调用执行过一次后，信号处理句柄又会被恢复成默认处理句柄值SIG_DFL。
在linux0.11源码中，include/signal.h文件中，默认句柄SIG_DFL和忽略处理句柄SIG_IGN的定义是：

#define SIG_DFL     ((void (*)(int))0)
#define SIG_IGN     ((void (*)(int))1)

signal()函数不可靠的原因在于当信号已经发生而进入自己设置的信号处理函数中，但在重新再一次设置自己的处理句柄之前，在这段时间内有可能又有同样的信号发生了。但是此时系统已经把处理句柄设置成默认值。因为就有可能造成信号丢失。
为了防止信号的丢失，sigaction()函数是比signal()函数更安全的选择。如果坚持要用signal()，可以在自己的信号处理函数开头再重新调用signal()函数做相同的处理。
而sigaction()函数比signal()函数更可靠的原因是，在信号处理函数正在处理时，被捕捉的信号在处理期间会被自动屏蔽，并且用struct sigaction结构体中的void (*sa_handler)(int)成员修改了信号的处理方式之后，除非再改回来，否则就一直使用修改之后的处理

最低0.47元/天 解锁文章
signal 和 sigaction 函数
qq_25626505的博客
09-17 1200
一、signal函数 signal()函数只处理一次信号； signal函数每次设置具体的信号处理函数只能生效一次， 每次在进程响应处理信号的时候，随即将信号处理函数恢复到默认方式；如果想多次以相同的方式处理某个信号，通常的做法是，在响应函数开始，再次设置signal； int sigint_handler(int sig) { signal(SIGINT, sigint_handler); ... } 看一个例子,此函数只能处理一次信号 void sigint_handler(int signo)
信号【2】-理解signal和sigaction
m0_46535940的博客
05-14 1026
文章目录前言一、signal对信号的处理1.1 **如果进程正在执行信号处理函数，这时又接收到一个相同的信号会怎样**？1.2 如果进程正在执行信号处理函数，这时又接收到一个不同的信号会怎样？1.3 针对可靠信号和不可靠信号signal又有如何表现？二、sigaction对信号的处理2.1 如果进程正在执行信号处理函数，这时又接收到一个相同的信号会怎样？2.2 如果进程正在执行信号处理函数，这时又接收到一个不同的信号会怎样？2.3 1.3 针对可靠信号和不可靠信号signal又有如何表现？2.4 一个细节总
如何正确使用sigaction设置信号处理器？90%的人都忽略了这一点！
最新发布
LiteTrans的博客
11-08 451
掌握C语言处理信号的sigaction配置关键技巧，避免常见陷阱。详解信号处理器设置方法、适用场景及结构体使用要点，提升程序稳定性。正确使用sigaction可精准控制信号行为，值得收藏。
Linux——sigaction信号捕捉函数
weixin_69283129的博客
07-11 6279
Linux_——针对sigaction信号捕捉函数的过程剖析，理解了进程在各个情况下对信号的接收规则。
signal和sigaction 分析
weixin_30762087的博客
06-29 416
1：signal 函数 　　原型：sighandler_t signal(int signum, sighandler_t handler) typedef void (*sighandler_t)(int); 　　描述：signal函数用来在进程中指定当一个信号到达进程后该做什么处理，主要的两种方式有忽略某些信号，(监听到SIGTERM/SIGINT)退出前的打扫工作。信号处理函...
signal和sigaction的分析比较
xiaofei0859的专栏
11-02 1039
signal函数每次设置具体的信号处理函数(非SIG_IGN)只能生效一次,每次在进程响应处理信号时，随即将信号处理函数恢复为默认处理方式.所以如果想多次相同方式处理某个信号,通常的做法是,在响应函数开始,再次调用signal设置,如下图: <br />int sig_int();//My signal handler<br /><br />    ...<br />    signal(SIGINT, sig_int);<br />    ...<br /><br />int sig_int()<br /
signal-defs.rar_The Signal
09-19
标题中的"signal-defs.rar_The Signal"暗示了我们讨论的主题是关于信号处理或通信系统中的信号定义。在IT行业中，特别是在...通过深入研究这些源文件，我们可以学习到更多关于操作系统、进程通信和音频处理的知识。
操作系统期中考核之自选题目研究（Linux下signal通信）
01-28
`signal()`函数简单但存在兼容性问题，而`sigaction()`函数则更强大，可以设置信号的处理方式、掩码和传递信息。 3. **信号掩码**： 信号掩码是当前进程不能处理的信号集合。通过`sigprocmask()`函数，我们可以...
7_signal 实现
11-24
在Linux操作系统中，进程间通信（IPC，Inter-Process Communication）是多个进程间交换数据的重要手段，其中信号（Signal）是一种轻量级的...通过深入研究和实验，你将能够灵活运用信号来解决复杂的同步和通信问题。
深入理解Android进程间通信机制
子者不语的专栏
08-29 2425
​通信是Android开发必不可少的一部分，不管是我们做应用App开发，还是Android系统，都使用了大量的通信。通信又分为进程间通信和进程内通信，在这篇文章，我主要深入讲解Android系统所涉及到的所有进程间通信方式。 Android系统中有大量IPC（进程间通信）的场景，比如我们想要创建一个新的进程，需要通过Socket这种IPC方式去让Zygote Fork新进程；如果我们要杀掉一个进程，需要通过信号这种IPC方式去将SIGNAL_KILL信号传递到系统内核；如果我们想要唤醒主线程处于休眠中的Lo
signal和sigaction的区别
conggai1647的博客
02-24 907
signal函数是为了兼容旧的，sigaction函数比signal函数更稳定，原因是在不同的unix系统里面signal函数会有不同，但sigaction函数完全相同。
信号：signal以及sigaction
MangoNova的博客
09-30 782
sigaction的一些重点
信号、signal 函数、sigaction 函数
脚踏实地，仰望星空
03-08 3102
1.信号的基本概念 2.利用 kill 命令发送信号 3.信号处理的相关动作 4.信号与 signal 函数 4.1 signal 函数示例一 4.2 signal 函数示例二 5.利用 sigaction 函数进行信号处理 6.利用信号处理技术消灭僵尸进程
信号捕捉（signal、sigaction）
luciusvorenus
04-01 2315
信号的基本属性：软中断，由内核发送，内核处理。某个进程通过内核向另一个进程发送信号时（引起信号产生的五个因素），另一个进程将会陷入内核进行中断处理，未决信号集中相应信号置1，当递达后，置0。如果阻塞信号集相应信号为1，则该信号处于未决状态。处于未决状态中的信号，多次发送时，只是执行一次，因为在未决信号集中只是记录了该信号的状态，没有记录发送的次数。信号抵达后，内核进行处理。处理方式有三：默认处理方...
十_信号10 - sigaction(),区别于 signal()
奶牛养殖场小马
02-26 705
signal()的缺陷1 ：当多个信号共用一个信号处理函数的时候，可能会发生重入，导致段错误。所以我们希望，在响应一个信号的时候，将其他信号阻塞。 sigaction()可以弥补 signal()的缺陷2 ：不能指定接收信号来源， sigaction()可以弥补 NAME sigaction, rt_sigaction - examine and change a signal action SYNOPSIS #include <signal.h>
信号、以及安装信号signal()与sigaction()函数讲解（实例代码）
m0_51429770的博客
04-06 1613
早期Unix系统中的信号机制比较简单和原始，信号值小于SIGRTMIN的信号都是不可靠信号。由于原来定义的信号已有许多应用，不好再做改动，最终只好又新增加了一些信号，并在一开始就把它们定义为可靠信号，这些信号支持排队，不会丢失。sigaction()==来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。对于信号发送函数来说也是一样的。之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。
sigaction函数和signal函数
黄晓伟
03-13 4851
signal和sigaction的区别： signal都是指以前的older signal函数，现在大多系统都用sigaction重新实现了signal函数。 1.      signal在调用handler之前先把信号的handler指针恢复；sigaction调用之后不会恢复handler指针，直到再次调用sigaction修改handler指针。这样，signal就会丢失信号，而且不能处
10 信号处理——signal、sigaction
Revendell的博客
09-05 1106
1、signal 各种事件促使内核向进程发送信号，包括用户的击键、进程的非法操作和计时器到时，一个进程调用signal在一下3种处理信号的方法之中选择： 默认操作（一般是终止进程），如signal(SIGALRM,SIG_DEL) 忽略信号，如signal(SIGALRM,SIG_IGN) 调用一个函数，如signal(SIGALRM,handler) signal的缺陷：signal处理根据不同版本不同选择 不可靠的信号：如果两个SIGINTS信号杀死了进程，意味着你的系统是不可靠信号，处理函数
nuttx中signal与semaphore的差异
08-28
<think>嗯，用户这次问的是NuttX中信号（signal）和信号量（semaphore）的差异。虽然之前讨论过信号机制，但用户现在需要对比这两者的区别，看来是进入了更深入的进程间通信（IPC）学习阶段。 从用户引用[1]的混乱描述看，ta可能正在研究底层实现时遇到了概念混淆——这恰好说明区分signal和semaphore非常必要。用户应该是个嵌入式开发者，因为NuttX通常用在物联网设备中。 需要从三个维度展开对比： 第一维度是本质差异：信号是异步事件通知（类似中断），而信号量是同步资源计数器。举个具体例子，当线程A等待信号量时会被阻塞，但等待信号时仍能执行主程序。 第二维度是使用场景。信号更适合处理异常（比如SIGSEGV）或用户中断（Ctrl+C的SIGINT），而信号量适合保护共享资源（比如SPI总线访问）。用户如果做传感器开发，SPI总线冲突用信号量解决更合适。 第三维度要强调资源消耗。在NuttX这种RTOS里，信号量结构体只有计数器+等待队列（约12字节），而信号需要维护处理函数链表——这对STM32这类内存<64KB的设备很关键。 突然想到用户可能混淆了“信号”和“信号量”的命名相似性。其实英文原文更清晰：signal是中断通知，semaphore是铁路信号灯式的资源标志。这个比喻应该能帮助ta理解。 最后要提醒信号处理的坑：NuttX的sa_flags不自动校验，这点和Linux不同。如果用户从Linux转过来，特别容易在这里踩雷。</think>在NuttX中，**信号（Signal）** 和**信号量（Semaphore）** 是两种完全不同的进程间通信（IPC）机制，核心差异如下： --- ### 1. **本质与用途** | **机制** | **本质** | **主要用途** | |-----------|--------------------------|------------------------------------------| | **信号** | **异步事件通知** | 处理异常、中断或进程间简单通知（如`SIGKILL`终止进程） | | **信号量**| **同步资源计数器** | 控制对共享资源的访问（如临界区保护、任务同步） | --- ### 2. **工作方式对比** #### **信号（Signal）** - **异步触发**：信号由内核或进程发送，目标进程**被动响应**。 - **处理流程**： 1. 注册信号处理函数（如`sigaction()`）。 2. 信号到达时，进程暂停当前执行流，跳转到处理函数。 3. 处理完成后恢复原上下文（若未被终止）。 - **示例**： ```c void handler(int sig) { /* 处理SIGUSR1 */ } signal(SIGUSR1, handler); // 注册处理函数 kill(pid, SIGUSR1); // 向目标进程发送信号 ``` #### **信号量（Semaphore）** - **同步操作**：任务**主动请求/释放**信号量。 - **核心操作**： - `sem_init()`：初始化信号量计数器（如初始值=1）。 - `sem_wait()`：尝试获取信号量（计数器-1），若计数器=0则阻塞。 - `sem_post()`：释放信号量（计数器+1），唤醒阻塞任务。 - **示例**： ```c sem_t sem; sem_init(&sem, 0, 1); // 初始化二进制信号量（互斥锁） sem_wait(&sem); // 进入临界区（阻塞直到获取） /* 访问共享资源 */ sem_post(&sem); // 离开临界区（释放） ``` --- ### 3. **关键差异总结** | **特性** | **信号（Signal）** | **信号量（Semaphore）** | |------------------|--------------------------------|--------------------------------| | **触发方式** | 被动接收（异步） | 主动请求/释放（同步） | | **资源管理** | 无资源计数概念 | 通过计数器管理资源 | | **阻塞行为** | 处理函数执行时可能中断主流程 | `sem_wait()`可能阻塞任务 | | **数据传递** | 仅传递信号编号（无数据负载） | 不传递数据，仅控制资源访问 | | **优先级反转** | 不涉及 | 需设计优先级继承机制避免[^1] | | **适用场景** | 错误处理、强制终止、简单通知 | 资源互斥、任务同步、生产者-消费者模型 | --- ### 4. **典型场景示例** - **信号**： 硬件异常（如除零错误触发`SIGFPE`）或用户按下`Ctrl+C`（发送`SIGINT`）终止进程。 - **信号量**： 多任务竞争SPI总线时，通过二进制信号量实现互斥访问；或任务A等待任务B完成数据采集后通过计数信号量同步。 --- ### 5. **资源开销与实时性** - **信号**： 上下文切换开销较大（需保存/恢复执行现场），可能影响实时性[^2]。 - **信号量**： 轻量级阻塞（任务挂起不消耗CPU），适合资源严格的嵌入式场景。 > ⚠️ **注意**：NuttX中信号处理存在`sa_flags`未严格检查等限制，需谨慎使用[^2]；而信号量需预防优先级反转问题（建议结合优先级继承协议）[^1]。 --- ### 总结 - **选择信号**：处理异步事件（如中断、错误）或简单进程控制。 - **选择信号量**：管理共享资源或需要精确同步的任务协作。 在资源受限的嵌入式系统中，信号量因确定性更高，更常用于核心逻辑的同步控制[^1][^2]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值