信号【1】-linux内核信号的处理过程（信号安全，可重入函数）

已于 2023-01-30 10:56:56 修改
阅读量942 收藏 3
点赞数
分类专栏： linux驱动开发 文章标签： linux驱动 linux 驱动开发
于 2022-05-10 11:31:15 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_46535940/article/details/124680187
版权

系列文章目录

linux【1】内核信号的处理过程
信号【2】-理解signal和sigaction
信号【3】- 理解sleep函数
信号【4】-理解实时信号
信号【5】-理解sigsuspend
信号【N】-linux信号编程的buglist

文章目录

前言

从今天开始在手撸一遍以前没写过的代码同时，认真的对其中的信号知识点做一次总结，主要为纵向和横向比较

  1. 如何使用信号编程以及陷阱在哪里？
  2. 信号从产生到死亡经历了什么？

21.1 设计信号处理器函数

Malloc函数的线程安全与可重入性分析
在执行malloc的过程中，跳转到了信号处理函数中。而信号处理函数在调用某个系统api时，内部又调用了malloc。 看了glibc源码就会知道，malloc内部也是有锁、而且是非嵌套的，如果在上一次调用中拿到锁，又跳转到信号处理函数中再次malloc，自然就导致死锁了。而且即使没有死锁，也极有可能破坏malloc内部维护的一些全局信息，导致后面莫名其妙的崩溃;由此可见，对于信号处理函数“必须保证可重入”这一点，在实际编码中必须慎之又慎，时刻谨记。
一般来说，信号处理函数中要做的事情应该尽量简单。通常可以置一个标识，由其他线程检测到这个标识后再做相应处理，而不是直接在信号处理函数中做这些事情。

说到信号处理函数的设计就不得不提：线程安全，可重入函数，异步信号安全。这是不同的三个概念。
线程安全针对竞争而言，数据需要共享就加锁，不需要共享就每个线程私有。
异步信号安全是指在线程编程时要处理异步的信号处理函数，在信号处理函数中以及线程中不管怎样调用你的函数都不会涉及可能变化的全局变量的访问，不发生死锁，就说明这个函数时异步安全的。
可重入函数一般说的可重入函数指的就是异步安全函数。事实上可重入函数又分弱可重入（线程安全），强可重入（异步信号安全）。那么一个函数时可重入的，那一定是线程安全的（反之不一定）。

  • 可重入函数一般需要满足

    • 不连续的调用长时间保持静态变量
    • 不返回指向静态变量的指针
    • 使用本地变量，或者通过制作静态变量的本地拷贝
    • 所有数据都由调用者提供
    • 绝不调用不可重入的函数

  • 线程安全但不可重入

    • 标准C的函数，因为标准C函数malloc/free等函数没有线程进程的概念，但是他们是线程安全的按不保证可重入

    21.1.1 Linux 多线程应用中编写安全的信号处理函数

    • 线程和信号
      linux多线程的应用中，每个线程可以通过pthread_sigmask()设置本线程的信号掩码。
      当一个线程调用pthread_create()创建新的线城时，本线程中的信号掩码被新创建的线程继承。
      应用程序也可以通过调用 pthread_kill(pthread_t thread, int sig) 将信号发送给指定的线程，则信号处理函数会在此指定线程的上下文背景中执行。

    • 安全的异步信号处理函数
      因为信号的异步事件，执行的上下文时不确定的。所以安全的异步信号处理函数有以下几种要求。

      • 信号处理器函数设置全局标志性变量越简单越好。主程序周期性对标志检测，一旦置位随即采取相应动作。
      • 从整个Linux应用的角度，应用使用了异步信号，程序中一些库函数可能会被中断返回异常，要考虑将其重新调用。

    • 在指定的线程中以同步的方式处理异步信号

    • 在指定的线程中处理信号
      sigwait
      sigwait() 提供了一种等待信号的到来，以串行的方式从信号队列中取出信号进行处理的机制。sigwait（）只等待函数参数中指定的信号集，即如果新产生的信号不在指定的信号集内，则 sigwait（）继续等待。对于一个稳定可靠的程序，我们一般会有一些疑问：

  • 多个相同的信号可不可以在信号队列中排队？

  • 如果信号队列中有多个信号在等待，在信号处理时有没有优先级规则？

  • 实时信号和非实时信号在处理时有没有什么区别？

笔者写了一小段测试程序来测试 sigwait 在信号处理时的一些规则。

清单 1. sigwait_test.c

#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>
#include <string.h> 
#include <stdlib.h> 

void sig_handler(int signum)
{
    printf("Receive signal. %d\n", signum);
}

void* sigmgr_thread()
{
    sigset_t   waitset, oset;
    int        sig;
    int        rc;
    pthread_t  ppid = pthread_self();

    pthread_detach(ppid);

    sigemptyset(&waitset);
    sigaddset(&waitset, SIGRTMIN);
    sigaddset(&waitset, SIGRTMIN+2);
    sigaddset(&waitset, SIGRTMAX);
    sigaddset(&waitset, SIGUSR1);
    sigaddset(&waitset, SIGUSR2);

    while (1)  {
        rc = sigwait(&waitset, &sig);
        if (rc != -1) {
            sig_handler(sig);
        } else {
            printf("sigwaitinfo() returned err: %d; %s\n", errno, strerror(errno));
        }
    }
}


int main()
{
    sigset_t bset, oset;
    int             i;
    pid_t           pid = getpid();
    pthread_t       ppid;

    sigemptyset(&bset);
    sigaddset(&bset, SIGRTMIN);
    sigaddset(&bset, SIGRTMIN+2);
    sigaddset(&bset, SIGRTMAX);
    sigaddset(&bset, SIGUSR1);
    sigaddset(&bset, SIGUSR2);

    if (pthread_sigmask(SIG_BLOCK, &bset, &oset) != 0)
        printf("!! Set pthread mask failed\n");

    kill(pid, SIGRTMAX);
    kill(pid, SIGRTMAX);
    kill(pid, SIGRTMIN+2);
    kill(pid, SIGRTMIN);
    kill(pid, SIGRTMIN+2);
    kill(pid, SIGRTMIN);
    kill(pid, SIGUSR2);
    kill(pid, SIGUSR2);
    kill(pid, SIGUSR1);
kill(pid, SIGUSR1);

    // Create the dedicated thread sigmgr_thread() which will handle signals synchronously
    pthread_create(&ppid, NULL, sigmgr_thread, NULL);

    sleep(10);

    exit (0);
}

程序编译运行在 RHEL4 的结果如下：

>>> kill -l
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
63) SIGRTMAX-1	64) SIGRTMAX

>>> a.out 
Receive signal. 10
Receive signal. 12
Receive signal. 34
Receive signal. 34
Receive signal. 36
Receive signal. 36
Receive signal. 64

图 1. sigwait 测试程序执行结果sigwait 测试程序执行结果
从以上测试程序发现以下规则：

对于非实时信号，相同信号不能在信号队列中排队；对于实时信号，相同信号可以在信号队列中排队。
如果信号队列中有多个实时以及非实时信号排队，实时信号并不会先于非实时信号被取出，信号数字小的会先被取出：如 SIGUSR1（10）会先于 SIGUSR2 (12)，SIGRTMIN（34）会先于 SIGRTMAX (64)， 非实时信号因为其信号数字小而先于实时信号被取出。
sigwaitinfo（） 以及 sigtimedwait() 也提供了与 sigwait（） 函数相似的功能。

  • Linux 多线程应用中的信号处理模型
    在基于 Linux 的多线程应用中，对于因为程序逻辑需要而产生的信号，可考虑调用 sigwait（）使用同步模型进行处理。其程序流程如下：
    • 主线程设置信号掩码，阻碍希望同步处理的信号；主线程的信号掩码会被其创建的线程继承；
    • 主线程创建信号处理线程；信号处理线程将希望同步处理的信号集设为 sigwait（）的第一个参数。
    • 主线程创建工作线程。
      图 2. 在指定的线程中以同步方式处理异步信号的模型在指定的线程中以同步方式处理异步信号的模型
      代码示例
      以下为一个完整的在指定的线程中以同步的方式处理异步信号的程序。

主线程设置信号掩码阻碍 SIGUSR1 和 SIGRTMIN 两个信号，然后创建信号处理线程sigmgr_thread（）和五个工作线程worker_thread（）。主线程每隔10秒调用 kill() 对本进程发送 SIGUSR1 和 SIGTRMIN 信号。信号处理线程 sigmgr_thread（）在接收到信号时会调用信号处理函数 sig_handler()。

程序编译：gcc -o signal_sync signal_sync.c -lpthread

程序执行：./signal_sync

从程序执行输出结果可以看到主线程发出的所有信号都被指定的信号处理线程接收到，并以同步的方式处理。

清单 2. signal_sync.c
#include <signal.h>
#include <errno.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>
 
void sig_handler(int signum)
{
    static int j = 0;
    static int k = 0;
    pthread_t  sig_ppid = pthread_self(); 
    // used to show which thread the signal is handled in.
   
    if (signum == SIGUSR1) {
        printf("thread %d, receive SIGUSR1 No. %d\n", sig_ppid, j);
        j++;
    //SIGRTMIN should not be considered constants from userland, 
    //there is compile error when use switch case
    } else if (signum == SIGRTMIN) {
        printf("thread %d, receive SIGRTMIN No. %d\n", sig_ppid, k);
        k++;
    }
}

void* worker_thread()
{
    pthread_t  ppid = pthread_self();
    pthread_detach(ppid);
    while (1) {
        printf("I'm thread %d, I'm alive\n", ppid);
        sleep(10);
    }
}

void* sigmgr_thread()
{
    sigset_t   waitset, oset;
    siginfo_t  info;
    int        rc;
    pthread_t  ppid = pthread_self();

    pthread_detach(ppid);

    sigemptyset(&waitset);
    sigaddset(&waitset, SIGRTMIN);
    sigaddset(&waitset, SIGUSR1);

    while (1)  {
        rc = sigwaitinfo(&waitset, &info);
        if (rc != -1) {
            printf("sigwaitinfo() fetch the signal - %d\n", rc);
            sig_handler(info.si_signo);
        } else {
            printf("sigwaitinfo() returned err: %d; %s\n", errno, strerror(errno));
        }
    }
}


int main()
{
    sigset_t bset, oset;
    int             i;
    pid_t           pid = getpid();
    pthread_t       ppid;
    

    // Block SIGRTMIN and SIGUSR1 which will be handled in 
    //dedicated thread sigmgr_thread()
    // Newly created threads will inherit the pthread mask from its creator 
    sigemptyset(&bset);
    sigaddset(&bset, SIGRTMIN);
    sigaddset(&bset, SIGUSR1);
    if (pthread_sigmask(SIG_BLOCK, &bset, &oset) != 0)
        printf("!! Set pthread mask failed\n");
    
    // Create the dedicated thread sigmgr_thread() which will handle 
    // SIGUSR1 and SIGRTMIN synchronously
    pthread_create(&ppid, NULL, sigmgr_thread, NULL);
  
    // Create 5 worker threads, which will inherit the thread mask of
    // the creator main thread
    for (i = 0; i < 5; i++) {
        pthread_create(&ppid, NULL, worker_thread, NULL);
    }

    // send out 5 SIGUSR1 and SIGRTMIN signals
    for (i = 0; i < 5; i++) {
        kill(pid, SIGUSR1);
        printf("main thread, send SIGUSR1 No. %d\n", i);
        kill(pid, SIGRTMIN);
        printf("main thread, send SIGRTMIN No. %d\n", i);
        sleep(10);
    }
    exit (0);
}

>>> a.out 
main thread, send SIGUSR1 No. 0
main thread, send SIGRTMIN No. 0
I'm thread 140412133189376, I'm alive
sigwaitinfo() fetch the signal - 10
thread 140412141582080, receive SIGUSR1 No. 0
sigwaitinfo() fetch the signal - 34
thread 140412141582080, receive SIGRTMIN No. 0
I'm thread 140412108011264, I'm alive
I'm thread 140412099618560, I'm alive
I'm thread 140412124796672, I'm alive
I'm thread 140412116403968, I'm alive
I'm thread 140412108011264, I'm alive
sigwaitinfo() fetch the signal - 10
thread 140412141582080, receive SIGUSR1 No. 1
I'm thread 140412133189376, I'm alive
main thread, send SIGUSR1 No. 1
main thread, send SIGRTMIN No. 1
I'm thread 140412116403968, I'm alive
I'm thread 140412124796672, I'm alive
sigwaitinfo() fetch the signal - 34
thread 140412141582080, receive SIGRTMIN No. 1
I'm thread 140412099618560, I'm alive
I'm thread 140412133189376, I'm alive
I'm thread 140412108011264, I'm alive
main thread, send SIGUSR1 No. 2
sigwaitinfo() fetch the signal - 10
thread 140412141582080, receive SIGUSR1 No. 2
sigwaitinfo() fetch the signal - 34
thread 140412141582080, receive SIGRTMIN No. 2
main thread, send SIGRTMIN No. 2
I'm thread 140412116403968, I'm alive
I'm thread 140412124796672, I'm alive
I'm thread 140412099618560, I'm alive
I'm thread 140412116403968, I'm alive
I'm thread 140412108011264, I'm alive
I'm thread 140412133189376, I'm alive
sigwaitinfo() fetch the signal - 10
thread 140412141582080, receive SIGUSR1 No. 3
I'm thread 140412099618560, I'm alive
I'm thread 140412124796672, I'm alive
main thread, send SIGUSR1 No. 3
main thread, send SIGRTMIN No. 3
sigwaitinfo() fetch the signal - 34
thread 140412141582080, receive SIGRTMIN No. 3
I'm thread 140412099618560, I'm alive
I'm thread 140412124796672, I'm alive
I'm thread 140412133189376, I'm alive
sigwaitinfo() fetch the signal - 10
thread 140412141582080, receive SIGUSR1 No. 4
main thread, send SIGUSR1 No. 4
sigwaitinfo() fetch the signal - 34
thread 140412141582080, receive SIGRTMIN No. 4
main thread, send SIGRTMIN No. 4
I'm thread 140412108011264, I'm alive
I'm thread 140412116403968, I'm alive
I'm thread 140412116403968, I'm alive
I'm thread 140412124796672, I'm alive
I'm thread 140412108011264, I'm alive

  • 注意事项
    在基于 Linux 的多线程应用中，对于因为程序逻辑需要而产生的信号，可考虑使用同步模型进行处理；而对会导致程序运行终止的信号如 SIGSEGV 等，必须按照传统的异步方式使用 signal（）、 sigaction（）注册信号处理函数进行处理。这两种信号处理模型可根据所处理的信号的不能同时存在一个 Linux 应用中：

    • 不要在线程的信号掩码中阻塞不能被忽略处理的两个信号 SIGSTOP 和 SIGKILL。
    • 不要在线程的信号掩码中阻塞 SIGFPE、SIGILL、SIGSEGV、SIGBUS。
    • 确保 sigwait() 等待的信号集已经被进程中所有的线程阻塞。
    • 在主线程或其它工作线程产生信号时，必须调用 kill() 将信号发给整个进程，而不能使用 pthread_kill() 发送某个特定的工作线程，否则信号处理线程无法接收到此信号。
    • 因为 sigwait（）使用了串行的方式处理信号的到来，为避免信号的处理存在滞后，或是非实时信号被丢失的情况，处理每个信号的代码应尽量简洁、快速，避免调用会产生阻塞的库函数。

  • 小结
    在开发 Linux 多线程应用中， 如果因为程序逻辑需要引入信号， 在信号处理后程序仍将继续正常运行。在这种背景下，如果以异步方式处理信号，在编写信号处理函数一定要考虑异步信号处理函数的安全； 同时， 程序中一些库函数可能会被信号中断，错误返回，这时需要考虑对 EINTR 的处理。另一方面，也可考虑使用上文介绍的同步模型处理信号，简化信号处理函数的编写，避免因为信号处理函数执行上下文的不确定性而带来的风险。

22.3 可中断和不可中断的进程睡眠状态

由内核可知当使用阻塞式IO的时候，进程可分为可中断唤醒和不可中断唤醒，都是指的信号中断。

  • 那么在用户态进程和信号的关系是什么？
    其实内核经常令进程进入休眠状态，而休眠状态又分为两种。

    • TASK_INTERRUPTIBLE: 例如进程因为调用read等待数据到来而进入休眠状态，这个状态可长可短，这时候为该进程创造一个信号，进程被唤醒当前状态被打断而进入信号处理器。通过PS命令查看可被打断的进程其STAT段被标记为S。
    • TASK_UNINTERRUPTIBLE ：进程正在等待某种特定类型的事件，将磁盘I/O读写完成，如果为该进程产生一个信号，那么在进程摆脱当前，信号会被阻塞不会传递给当前进程。通过PS命令查看可被打断的进程其STAT段被标记为D。

5. 信号从产生到死亡经历了什么？

22.5 信号的同步生成和异步生成

信号无论是从其他进程发送过来，还是由内核发送过来，都是无法预测的，都属于异步产生。然而有时候信号的产生者是自身信号并发送给自己。

  • 执行特定的机器语言指令，可导致硬件异常
  • 进程可使用kill，raise，killpg向自身发送信号

以上这两种信号就是同步产生。对于同步产生的信号，其行为不仅可以预测还可以重现。

22.6 信号传递的时机与顺序

  • 进程再调度超时后,再度获得调度时（即一个时间片开始时）
  • 系统调用完成时

22.6.1 进程如何发现和接受信号

这里主要讨论异步信号的传递。一个进程的不可能等待信号的到来也不知道信号什么时候到来。**信号的传递不是由进程传递的，而是由内核代理，**例如，进程p2向进程p1发送信号，内核将信号放在p1的信号队列中，等p1再次被调度时会首先执行，会调用do_notify_resume()来处理信号队列中的信号。信号处理主要就是调用sighand_struct结构中对应的信号处理函数。do_notify_resume()(arch/arm/kernel/signal.c)函数的定义如下：linux内核中的信号机制–信号处理

asmlinkage void
do_notify_resume(struct pt_regs *regs, unsigned int thread_flags, int syscall)
{
	if (thread_flags & _TIF_SIGPENDING)
		do_signal(&current->blocked, regs, syscall);
}

在这里插入图片描述

22.6.2 信号检测和响应时机

[root@localhost stack_dump]# cat /proc/20254/task/20255/stack
[<ffffffff81432637>] __skb_recv_datagram+0x237/0x290
[<ffffffff8149861b>] udp_recvmsg+0x8b/0x310
[<ffffffff8149f85a>] inet_recvmsg+0x5a/0x90
[<ffffffff81426693>] sock_recvmsg+0x133/0x160
[<ffffffff81426d5e>] sys_recvfrom+0xee/0x180
[<ffffffff8100b0d2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
 
 
 
[root@localhost stack_dump]# kill -11 20255
[root@localhost stack_dump]# Stack trace (non-dedicated):
./funstack() [0x400c16]
/lib64/libpthread.so.0() [0x31cf40f7e0]
/lib64/libpthread.so.0(recvfrom+0x33) [0x31cf40eca3]
./funstack(func1+0xd8) [0x400de5]
./funstack(test_func+0xe) [0x400e11]
./funstack(task_entry+0x16) [0x400e29]
/lib64/libpthread.so.0() [0x31cf407aa1]
/lib64/libc.so.6(clone+0x6d) [0x31ce8e893d]
End of stack trace
recvfrom over

经过实验可知，信号检测并非再系统调用返回前夕，而是在本进程再次获得调度机会时。

22.6.3 进入信号处理函数

由以上可知，信号处理函数在用户态，但是发现信号处理函数在内核态，如何进程状态变换呢？
有以下图可知，系统先从内核态转到用户态，再回到内核态，再跳到用户态。
在这里插入图片描述
如图中所见，处理信号的整个过程是这样的：进程由于 系统调用或者中断 进入内核，完成相应任务返回用户空间的前夕，检查信号队列，如果有信号，则根据信号向量表找到信号处理函数，设置好“frame”（栈帧）后，跳到用户态执行信号处理函数。信号处理函数执行完毕后，返回内核态，设置“frame”，再返回到用户态继续执行程序。

22.6.4 为什么要设置frme，为什么执行完信号函数之后还要回到内核态？

什么叫Frame？

在调用一个子程序时，堆栈要往下（逻辑意义上是往上）伸展，这是因为需要在堆栈中保存子程序的返回地址，还因为子程序往往有局部变量，也要占用堆栈中的空间。此外，调用子程序时的参数也是在堆栈中。子程序调用嵌套越深，则堆栈伸展的层次也越多。在堆栈中的每一个这样的层次，就称为一个”框架”，即frame。

一般来说，当子程序和调用它的程序在同一空间中时，堆栈的伸展，也就是堆栈中框架的建立，过程主要如下：

call指令将返回地址压入堆栈（自动）
用push指令压入调用参数
调整堆栈指针来分配局部变量
为什么以及怎么设置frame？

我们知道，当进程陷入内核态的时候，会在堆栈中保存中断现场。因为用户态和内核态是两个运行级别，所以要使用两个不同的栈。当用户进程通过系统调用刚进入内核的时候，CPU会自动在该进程的内核栈上压入下图所示的内容：（图来自《Linux内核完全注释》）
在这里插入图片描述
在处理完系统调用以后，就要调用do_signal()函数进行设置frame等工作。这时内核堆栈的状态应该跟下图左半部分类似（系统调用将一些信息压入栈了）：
在这里插入图片描述
在找到了信号处理函数之后，do_signal 函数首先把内核堆栈中存放返回执行点的 eip 保存为old_eip，然后将 eip 替换为信号处理函数的地址，然后将内核中保存的“原ESP”（即用户态栈地址）减去一定的值，目的是扩大用户态的栈，然后将内核栈上的内容保存到用户栈上，这个过程就是设置frame.值得注意的是下面两点：

之所以把EIP的值设置成信号处理函数的地址，是因为一旦进程返回用户态，就要去执行信号处理程序，所以EIP要指向信号处理程序而不是原来应该执行的地址。

之所以要把 frame 从内核栈拷贝到用户栈，是因为进程从内核态返回用户态会清理这次调用所用到的内核栈（类似函数调用），内核栈又太小，不能单纯的在栈上保存另一个frame（想象一下嵌套信号处理），而我们需要EAX（系统调用返回值）、EIP这些信息以便执行完信号处理函数后能继续执行程序，所以把它们拷贝到用户态栈以保存起来。

以上这些搞清楚之后，下面的事情就顺利多了。这时进程返回用户空间，就会根据内核栈中的EIP值执行信号处理函数。那么，信号处理程序执行完后，怎么返回程序继续执行呢？

22.6.5 信号处理函数执行完后怎么办？

信号处理程序执行完毕之后，进程会主动调用 sigreturn() 系统调用再次回到内核（可以通过strace来进行验证），查看有没有其他信号需要处理，如果没有，这时内核就会做一些善后工作，将之前保存的frame恢复到内核栈，恢复eip的值为old_eip，然后返回用户空间，程序就能够继续执行。至此，内核遍完成了一次（或几次）信号处理工作。

6. 信号掩码

6.1 信号掩码是什么？

内核为每个进程维护一组信号掩码，用来阻塞针对该进程的信号的传递。
当将遭阻塞的信号传递给进程，这个信号会被阻塞挂起，延迟传送，直至进程从信号掩码集中将其清除，从而解除阻塞为止。

6.3 什么时候需要阻塞信号的传递

当进程执行一段上下文的时候，不希望被某一个信号打断，可以显示的使用系统调用sigpromask(),将信号阻塞，然后再显示的释放对该信号的阻塞。这样就可以暂时阻止信号的传递。

```c
/*暂时阻塞信号的传递*/
sigset_t blockSet,prevMask;
/*初始化一个信号集包含SIGINT*/
sigemptyset(&blockSet);
sigaddSet(&block,SIGINT);
/*阻塞SIGINT,保存先前的信号掩码*/
if (sigprocmask(SIG_BLOCK,&blockSet,&prevMask) == -1)
	exit(0);
/*不应该被SIGINT打断的代码上下文*/
。。。。。。。。
/*恢复之前的信号掩码集，解除对SIGINT的阻塞*/
if (sigprocmask(SIG_SETMASK,&prevMask,NULL) == -1)
	exit(0)


如果任何信号因为调用sigprocmask而阻塞的，那么一旦解除阻塞，那么会立即将该信号传递给进程。

- 信号被传递的优先级
	实时信号可以做入队处理，如果不同的信号同时传递给进程，那么信号数字越小的信号优先级越高，被优先传递（目前有待验证）
	
```c
#define _GUN_SOURCE
#include <string.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

static void handler(int sig)
{
    printf("PID=%ld:caught signal %d (%s)\n",(long)getpid(),sig,strsignal(sig));
}

int main(int argc, char **argv)
{
    int j;
    struct sigaction sa;
    sigset_t blockSet,prevMask;

    if(argc < 2 || strcmp(argv[1],"--help") == 0){
        exit(0);
    }

    setbuf(stdout,NULL);
    sigemptyset(&sa.sa_mask);
	sigaddset(&sa.sa_mask,SIGIO);

    sa.sa_flags = 0;
    sa.sa_handler = handler;
    if (sigaction(SIGHUP,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGCONT,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGIO,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGUSR1,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGRTMIN,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGUSR2,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGRTMAX - 1,&sa,NULL) == -1)
        exit(0);
    if (sigaction(SIGRTMAX,&sa,NULL) == -1)
        exit(0);
	sigemptyset(&blockSet);
	sigaddset(&blockSet,SIGIO);
    sigaddset(&blockSet,SIGUSR1);
    sigaddset(&blockSet,SIGRTMIN);
    sigaddset(&blockSet,SIGUSR2);
    sigaddset(&blockSet,SIGRTMAX - 1);
    sigaddset(&blockSet,SIGRTMAX);

	sigprocmask(SIG_BLOCK,&blockSet,&prevMask);
    kill(getpid(),SIGIO);
    kill(getpid(),SIGUSR1);
    kill(getpid(),SIGUSR2);
    kill(getpid(),SIGRTMIN);
    kill(getpid(),SIGRTMIN);
    kill(getpid(),SIGRTMIN);
    kill(getpid(),SIGRTMAX - 1);
    kill(getpid(),SIGRTMAX);
    sleep(3);
    sigprocmask(SIG_SETMASK,&prevMask,NULL);
    sleep(3);
    printf("parent:PID=%ld,PPID=%ld,PGID=%ld,SID=%ld\n",
            (long)getpid(),(long)getppid(),
            (long)getpgrp(),(long)getsid(0));
    for (j = 1; j < argc; j++){
        switch(fork()){
            case -1:
                exit(-1);
            case 0:
                printf("child:PID=%ld,PPID=%ld,PGID=%ld,SID=%ld\n",
                        (long)getpid(),(long)getppid(),
                        (long)getpgrp(),(long)getsid(0));
                if (argv[j][0] == 's'){ /*stop via signal*/
                    printf("PID=%ld stopping\n",(long)getpid());
                    raise(SIGSTOP);
                }else{
                    alarm(60);
                    printf("PID=%ld pausing\n",(long)getpid());
                    pause();
                }
                _exit(EXIT_SUCCESS);
            default:
                break;
        }
        sleep(3);
        printf("parent exiting\n");
        exit(EXIT_SUCCESS);
    }
    return 0;
}

>>> a.out s
PID=4930:caught signal 64 (Real-time signal 30)
PID=4930:caught signal 63 (Real-time signal 29)
PID=4930:caught signal 34 (Real-time signal 0)
PID=4930:caught signal 34 (Real-time signal 0)
PID=4930:caught signal 34 (Real-time signal 0)
PID=4930:caught signal 12 (User defined signal 2)
PID=4930:caught signal 10 (User defined signal 1)
PID=4930:caught signal 29 (I/O possible)
parent:PID=4930,PPID=4241,PGID=4930,SID=4241
child:PID=4961,PPID=4930,PGID=4930,SID=4241
PID=4961 stopping

6.3 在讨论信号优先级传递

  • 为什么信号分为可靠信号与不可靠信号
    由上可知，不可靠信号即使发多少次只被传递了一次。而可靠信号会排队处理。
    这是因为现在的信号机制是从unix继承而来，事实证明会有很多不好的现象出现。
    • 1-31信号不可靠信号会丢失。
    • 早期的unix定义不可靠的信号是指进程可能对不可靠的信号做出错误反应或者丢失
    • Linux支持不可靠信号，并改进了unix对不可靠信号处理完毕还要重新安装的缺点。
    • 目前Linux不可靠信号指的是信号的丢失。
      非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号

总结

大城市的小蜗牛
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Linux内核中的信号机制??信号处理
01-09
当进程被调度时，会调用do_notify_resume()来处理信号队列中的信号。信号处理主要是调用sighand_struct结构中对应的信号处理函数。do_notify_resume()(arch/arm/kernel/signal.c)函数的定义如下： asmlinkage void do_notify_resume(struct pt_regs *regs， unsigned int thread_flags， int syscall) {  if (thread_flags & _TIF_SIGPENDING)   do_signal(&current->blocked，
LINUX 信号处理
smilejiasmile的博客
08-19 428
LINUX 信号处理 1、信号的基本概念            信号是进程在运行过程中， 由自身产生或由进程外部发过来的消息（事件）。信号是硬件中断的软件模拟(软中断)。每个信号用一个整型常量宏表示， 以 SIG 开头， 比如 SIGCHLD、 SIGINT 等，它们在系统头文件中定义,也可以通过在 shell 下键入kill –l 查看信号列表，或者键入 man 7 signal
linux 多线程 信号
yangruibao的专栏
10-28 1977
在开发linux mjpg-streamer程序的时候，使用signal，奇怪的是程序竟然退出了。后来读了曹老师的文章，才解决了这个问题。 所以收录到自己的博客里。呵呵 多线程中定时器的使用41865100619 2010-10-14 19:47:29                                                             ——
linux的进程与线程
wintree的专栏
03-09 1899
在许多经典的操作系统教科书中，总是把进程定义为程序的执行实例，它并不执行什么，只是维护应用程序所需的各种资源。而线程则是真正的执行实体，为了让进程完成一定的工作，进程必须至少包含一个线程。进程所维护的是程序所包含的资源（静态资源），如：地址空间，打开的文件句柄集，文件系统状态，信号处理handler等。 线程所维护的是运行相关的资源（动态资源），如：运行栈，调度相关的控制信息，待处理的信号集等。
Linux系统之信号及处理流程（图详解）
Go_bro的博客
10-15 1928
关于Linux系统（信号篇） 引言：信号机制是一种使用信号来进行进程之间传递消息的方法，信号的全称为软中断信号，简称软中断。信号的本质是软件层次上对中断的一种模拟（软中断）。它是一种异步通信的处理机制，事实上，进程并不知道信号何时到来。Linux系统一共有64个信号，其中1-31信号供应用开发者使用 34-64信号供驱动开发者使用，如图。 信号是什么？ 信号是由用户、系统或进程发送给目标进程的信息，以通知目标进程摸个状态的改变或系统异常。 *信号处理的优先级是大于系统调用的。 看几种常用的信
Linux内核中的信号机制??信号发送
01-09
应用程序发送信号时，主要通过kill进行。注意：不要被“kill”迷惑，它并... 　● pid=-1：信号被发送到任何一个进程，init进程（PID=1）和以及当前进程无法发送信号的进程除外。 　● pid<-1：信号被发送到目标进
linux-linux内核源码分析.zip
最新发布
02-26
Linux内核提供了信号量、自旋锁、读写锁等同步原语。理解这些机制如何确保内核数据的安全访问，是分析内核源码的重要环节。 9. **模块化设计**：Linux内核允许动态加载和卸载模块，这使得内核更加灵活。理解模块的...
Linux下的信号详解及捕捉信号
09-15
其中，`signum`参数是信号的编号，`handler`是处理函数的指针，当信号发生时，内核会调用这个函数。 信号的处理并不总是立即进行，而是会在适当的时机，如中断返回或从内核态回到用户态时处理。这是因为立即处理...
01--Linux系统编程-信号.docx
11-10
Linux内核通过进程控制块（PCB，即task_struct结构体）来存储关于信号的信息，包括阻塞信号集和未决信号集。阻塞信号集允许进程临时屏蔽某些信号，使其不会立即处理，而是等到解除屏蔽后处理。未决信号集则记录了...
信号处理的流程linux,linux信号处理机制
weixin_34672875的博客
05-15 517
学习一下信号的处理机制。一、信号的产生信号是有可能来自内核，也有可能来自进程。当然，最根本的来源是信号产生函数。其实就是通过内核更新目标进程的数据结构以表示一个信号已经被发送。其中为进程产生信号的函数有：函数名说明send_sig()向单一进程发送信号send_sig_info()与send_sig()类似，只是还使用siginfo_t结构中的扩展信息force_sig()发送既不能被进程显示忽略...
【Linux】信号的处理
Sxy_wspsby的博客
05-13 3144
在前两篇linux文章中我们详细的讲解了信号的产生和信号的保存，今天来到最后一个重点信号的处理，对于信号的处理我们会重新引入进程地址空间的知识，并且我们会详细的介绍内核是如何对信号进行捕捉的以及什么是可重入函数。以上就是我们信号处理的所有内容了，对于信号处理这个章节我们需要理解进程地址空间以及内核是如何进行信号捕捉的，下一篇我们发布的linux文章是线程。
Linux内核：进程管理——进程信号处理流程
m0_74282605的博客
04-07 180
两个直观的感受，你在终端运行一个程序然后摁一下Ctrl+c就是向正在运行的程序发送了一个终止信号，程序就被终止了；在终端kill一个pid相当于发送9号杀死这个进程；在终端运行kill -l 就可以查看系统的所有信号。那么信号本质是什么呢？信号本质上是一种向一个进程通知发生异步事件的机制，是在软件层次上对中断的一种模拟。这种通知机制可以用于通知硬件消息like上面的感受1，也可以用来进行进程间通信like上面的感受2，还可以用来通知一些程序错误如除0、非法内存访问。异步是说进程没有对信号进行实时监控，不必等
Linux系统编程（四）——signal信号处理
Alkaid2000的博客
11-26 2706
Linux中的信号处理以及信号处理函数
初步理解Linux进程信号的处理过程 + Linux常见信号
challenglistic的博客
04-26 3089
初步了解进程信号的特点、信号处理函数signal 以及 Linux已有的信号
linux系统下进程的信号处理流程
Chasing__Dreams的博客
05-23 1968
一、什么是信号？ 1、信号本质 软中断信号（signal，又简称为信号）用来通知进程发生了异步事件。在软件层次上是对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是进程间通信机制中唯一的异步通信机制，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。 2、信号来源 硬件来源: 用户按终端键，引起终端产生的信号（如：CTRL+C、CTRL+\，CTRL+Z等）。 硬件异常产生信号：内核检测到段错误、管道破裂等、除数为0、无效的
Linux进程信号的处理
分享学习的知识，记录我的技术成长道路
07-27 960
信号的发送与进程间通信是不同的，信号只能够由操作系统来进行发送，而进程的作用是请求操作系统来发送信号。我们使用control+C可以终止一个进程的本质上其实就是向该进程发送一个2号信号。信号的内容有很多，总结起来可以分为三个大方向信号产生前，信号产生中，信号产生后。信号的产生共有四种方式，分别是由键盘产生，进程崩溃产生，系统调用产生，和软件条件产生。信号产生中要记住三张表以及它们代表的含义。以及处理三张表的各种接口。httpshttpshttpshttpshttpshttps。...
linux 信号处理
zhuguanghong的博客
07-13 638
1 linux中的信号Linux中的信号是用来通知进程发生了异步事件。在原理上，一个进程收到一个信号与一个处理器收到一个中断请可以看成一致的。信号是linux进程间通信机制中的唯一的异步通信机制，一个进程不必通过任何操作来等待信号的到达，事实上，进程也无法提前感知信号什么时候到达由谁发送。当然内核也会因为内部事件给进程发送信号。信号机制除了基本通知功能外，还可以传递附加信息。常用的信号发送函数有raise kill等 常用的信号注册函数有signal、sigaction等。2 源码分析2.1 信号发送此处拿
Linux：信号（注册，注销，处理，阻塞）
qq_45481606的博客
08-09 2164
信号的处理方式 1.默认处理方式（称为SIGDFL）： 一个进程收到ctrl c信号而终止，说明2号信号在内核中有与之对应的处理动作，该处理动作为默认处理动作 2.忽略处理方式（称为SIGIGN）： SIGCHLD：子进程再退出时给父进程发送一个SIGCHLD信号，父进程对于该信号的处理方式是忽略处理； 该信号对于所有进程而言都是忽略处理 3.自定义处理（是想要更改信号的处理方式，需要用到两个函数） signal函数 通过signal函数，把一个信号的处理方式改为了handler函数，当进程收
linux——linux信号1（基础认识）
2302_76515999的博客
04-12 131
捕捉信号：需要高速内核，用户希望如何处理某一种信号，说白了就是写一个信号处理函数，然后将这个函数高速内核。当该信号产生时，由内核来调用用户自定义的函数，以此来实现某种信号的处理。比如，终端用户输入了ctrl+c来中断程序，会通过信号机制停止一个程序。忽略信号：大多数信号可以使用这个方式来处理。系统默认动作：对于每个信号来说，系统对应默认的处理动作，当发生了该信号，系统会自动执行。信号定义在 signal.h，头文件中，信号名都定义为正整数。比如敲门——需要开门，手机响了——需要接通，信号优先级。
linux内核中信号处理全过程是怎样的
03-30
Linux内核中的信号处理过程可以概括为以下几个步骤： 1. 发送信号：当一个进程需要向另一个进程或者自身发送信号时，可以调用kill或者raise函数，或者在终端中使用Ctrl+C等信号来发送信号。 2. 中断当前进程：当...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值