【Linux】--进程信号

信号

1.信号入门

1. 程序员设计进程的时候，早就已经设计了对信号的识别能力！！！！
2. 进程在没有收到信号的时候，其实它早就已经知道一个信号该怎么处理了！
3. 因为信号可能随时会产生，所有在信号产生前，我可能正在做优先级更高的事情，我可能不能立马处理这个信号！我们要在合适的时候进行处理，同理进程收到信号的时候，如果没有立马处理这个信号，就需要进程具有记录信号的能力！
4. 信号的产生对于进程来说是异步的
5. 进程先描述在组织对应产生的信号，并使用位图这一个数据结构进行记录
6. 所谓的发送信号，本质其实是写入信号。直接修改特定进程的信号位图中的特定比特位。(0->1)
7. task_struct 属于内核数据结构，只能由OS进行修改–无论后面有多少种信号产生的方式，最终都必须让OS来完成最后的发送过程！
8. 信号产生之后，不是立即处理的，是在合适的时候。

2.技术应用角度的信号

用户输入命令，在Shell下启动一个前台进程。

我们可以看到，使用./mysignal来运行可执行文件之后，我们可以通过ctrl+Z或者ctrl+C来停止终止程序。在这个过程中如果我们想使用其他的命令，比如pwd是无法使用的。这就是我们的前台进程


我们看到如果使用./signal &那来运行程序，我们可以发现还是可以使用我们的命令，这就是后台程序。并且我们用ctrl+c无法终止，只有配合kill+pid来杀掉进程。

• 用户按"Ctrl+C“，这个键盘输入产生一个硬件中断，被OS获取，解释成信号，发送给目标前台进程

• 前台进程因为收到信号，进而引起程序退出
  注意

• ctrl+c产生的信号只能发给前台进程，一个命令后面加个&可以放到后台运行，遮阳Shell不必等待进程结束就可以接收新的命令，启动新的进程。

• Shell可以同时运行一个前台进程和多个后台进程，只有前台进程才能接到像ctrl+c这种控制键产生的信号。

• 前台进程在运行过程中用户随时都可能按下ctrl+c而产生一个信号，也就是说该进程的用户空间代码执行到任何地方都有可能收到SIGINT信号而终止，所以信号相对于进程的控制流程来说是异步（Asynchronous）的。
  注意

• ctrl+ c产生的信号只能发给前台进程。一个命令后面加个&可以放到后台运行，这样Shell不必等待进程结束就可以接收新的命令，启动新的进程。

• Shell可以同时运行一个前台进程和任意多个后台进程，只有前台进程才能接到像ctrl+c这种控制键产生的信号

• 前台进程在运行过程中用户随时可能按下Ctrl+c，而产生一个信号，也就是说该进程的用户空间代码执行到任何地方都有可能收到SIGINT信号而终止，所以信号相对于进程的控制来说是异步的。

3.信号概念

信号是进程之间事件异步通知的一种方式，属于软中断。

kill -l查看系统定义的信号列表

• 每个信号都有一个编号和一个宏定义名称，这些宏定义可以在signal.h中找到，例如其中有定义#define SIGINT 2
• 编号34以上的是实时信号，我们暂时不讨论

---

处理信号的方式：

1. 默认动作
2. 忽略信号
3. 用户自定义行为

2.产生信号

下面来看一段简单的代码，我们通过实例来看进程产生信号的方式
Makefile

mysignal:mysignal.cc
   g++ -o $@ $^ -std=c++11
.PHONY:clean
clean:
   rm -f mysignal

mysignal.cc

#include
#include

int main()
{
    while(true)
    {
        std::cout<<"我是一个进程，我正在运行...,pid："<<getpid()<<std::endl;
        sleep(1);
    }
    return 0;
}

1.通过终端按键产生信号

SIGINT的默认处理动作是终止进程，SIGQUIT的默认动作是终止进程并且Core Dump，现在我们来验证一下。
Core Dump

首先解释一下，什么是Core Dump。当一个进程要异常终止时，可以选择把进程的用户空间内存数据全部保存到磁盘上，文件名通常是Core ，这叫做Core Dump。进程异常终止通常是因为有Bug，比如非法内存访问导致段错误，事后可以用调试器检查Core文件以查清错误原因，这叫做Post-mortem Debug（事后调试）。一个进程允许产生多大的core文件取决于进程的Resource Limit（这个信息保存在PCB中）。默认是不允许产生core文件的，因为core文件中可能包含用户密码等敏感信息，不安全。在开发调试阶段可以用ulimit命令改变这个限制，允许产生core文件。首先用ulimit命令改变Shell进程的Resource Limit，允许core文件最大为1024K：$ulimit -c 1024

那么我们可以证明，按下Ctrl+c进程确实发送了信号吗？、
看下面这段代码
我们自定义了一个方法，如果检测到按下Ctrl+c（也就是2号信号），就执行我们方法里的代码。

mysignal.cc文件

#include
#include
#include
//自定义方法
void handler(int signo)
{
    std::cout<<"get a siganl :"<<signo<<std::endl;
}

int main()
{
    signal(2,handler);
    while(true)
    {
        std::cout<<"我是一个进程，我正在运行...,pid："<<getpid()<<std::endl;
        sleep(1);
    }
    return 0;
}

运行结果：

可以看到我们在按下ctrl+c之后确实执行了我们自定义的方法，但是现在却无法终止程序。我们可以合理推测：1、ctrl+c确实向终端发送了2号信号；2、2号信号对应系统的默认处理方法是终止进程；3、singal（2，handler）调用完这个函数的时候，handler方法没有被调用，只是更改了2号信号的处理动作，并没有调用handler方法。而是在2号信号产生的时候被调用。

我们如果把1~31号信号的处理方法都自定义为handler，那么我们的程序还可以退出吗？

#include
#include
#include
//自定义方法
void handler(int signo)
{

    std::cout<<"get a siganl :"<<signo<<std::endl;
}

int main()
{
    for(int i=1;i<=31;i++)
    {
        signal(i,handler);

    }
    while(true)
    {
        std::cout<<"我是一个进程，我正在运行...,pid："<<getpid()<<std::endl;
        sleep(1);
    }
    return 0;
}

我们可以看到ctrl+c，ctrl+z，ctrl+\都无法终止程序，但是我们使用kill -9+uid，还是可以杀掉程序。9号信号是管理员信号，是无法自定义方法的，只能执行默认方法。

我们平时在输入的时候，计算机怎么知道我从键盘中输入了数据呢？键盘是通过硬件中断的方式，通知系统，我们的键盘已经按下。

2.调用系统函数向进程发信号

kill
运行
首先在后台执行死循环程序，然后用kill命令给它发SIGSEGV

mykill.cc

#include
#include
#include
#include
#include
#include
#include
void Usage(std::string proc)
{
    std::cout<<"Usage:\n\t";
    std::cout<<proc<<"./信号编号 目标进程\n"<<std::endl;
}
int main(int argc,char* argv[])
{
    if(argc!=3)
    {
        Usage(argv[0]);
        exit(1);
    }
    int signo=atoi(argv[1]);
    int target_id = atoi(argv[2]);

    int n = kill(target_id,signo);
    if(n!=0)
    {
        std::cerr<<errno<<":"<<strerror(errno);
        exit(2);
    }
}

loop.cc

#include
#include

int main()
{
    while(true)
    {
        std::cout<<"我是一个进程，我正在运行...,pid:"<<getpid()<<std::endl;
        sleep(1);
    }
}

Makefile

.PHONY:all
all:mykill loop

loop:loop.cc
	g++ -o $@ $^ -std=c++11
mykill:mykill.cc
	g++ -o $@ $^ -std=c++11
.PHONY:clean
clean:
	rm -f mykill loop

运行结果：

可以看到我们自己编写的mykill函数和kill命令都达到了杀掉进程的目的。

raise
给当前进程发送指定信号（自己给自己发送信号）

#include 
int kill(pid_t pid, int signo);
int raise(int signo);
这两个函数都是成功返回0,错误返回-1。

abort
使当前进程接受到信号而异常终止

#include 
void abort(void);
就像exit函数一样,abort函数总是会成功的,所以没有返回值。

mykill.cc

#include
#include
#include
#include
#include
#include
#include
void myhandler(int signo)
{
    std::cout<<"get a signal:"<<signo<<std::endl;
}
int main(int argc,char* argv[])
{
    signal(SIGABRT,myhandler);
    while(true)
    {
        std::cout<<"begin"<<std::endl;
        sleep(1);
        abort();
        std::cout<<"end"<<std::endl;
    }
}

运行结果:

3.由软件条件产生信号

alarm这个函数的返回值是0或者是以前设定的闹钟剩余的秒数，比如我上一个闹钟设定的30s，但是我在闹钟还剩10s的时候醒了，然后重新设定了一个新的闹钟，这个新的闹钟的返回值就是10。

#include
#include
#include
#include
#include
#include
#include
void myhandler(int signo)
{
    std::cout<<"get a signal:"<<signo<<std::endl;
}

int main(int argc,char* argv[])
{
    int count=0;
    //设置一秒钟之后的闹钟
    alarm(1);
    while(true)
    {
        std::cout<<"count:"<<count<<std::endl;
        count++;
    }

运行结果;

可以看到最后的结果，一秒钟计算机将count累加到了11w，并输出到显示器上。由于我们云服务器会存在说网络问题，以及输出到显示器上会拖慢时间。所以这个最后的累加结果并不是我们准确的算力。

#include
#include
#include
#include
#include
#include
#include
int count=0;

void myhandler(int signo)
{
    std::cout<<"get a signal:"<<signo<<"   count:"<<count<<std::endl;
}

int main(int argc,char* argv[])
{
    signal(SIGALRM,myhandler);
    //设置一秒钟之后的闹钟
    alarm(1);
    while(true)
    {
        // std::cout<<"count:"<
        count++;
    }

4.硬件异常产生信号

硬件异常被硬件以某种方式被硬件检测到并通知内核，然后内核向当前进程发送适当的信号。例如当前进程执行了除0以外的指令，CPU的运算单元会产生异常，内核将这个异常解释为SIGFPE信号发送给进程。再比如当前进程访问了非法内存地址，MMU会产生异常，内核将这个异常解释为SIGSEGV信号发送给进程。
除0错误
除0的本质就是触发硬件异常（CPU）

mysignal.cc

#include
#include

using namespace std;
int main()
{
    int a = 10;
    a /= 0;

    cout<<"div zero..."<<endl;

    return 0;

}

Makefile

mysignal:mysignal.cc
	g++ -o $@ $^ -std=c++11
.PHONY:clean
clean:
	rm -f mysignal

我们继续完善mysignal.cc，对除0产生的信号进行捕捉。

#include
#include

using namespace std;

void handler(int signo)
{
    cout<<"我们的进程确实是收到了："<<signo<<"信号导致崩溃的"<<endl;
    exit(1);
}

int main()
{
    signal(SIGFPE,handler);
    int a = 10;
    a /= 0;
    cout<<"div zero..."<<endl;

    return 0;

}

和我们预期一样，捕捉到的信号调用了我们自定义的方法（handler），并且捕捉的信号是8号信号。

野指针

#include
#include

using namespace std;

void handler(int signo)
{
    cout<<"我们的进程确实是收到了："<<signo<<"信号导致崩溃的"<<endl;
    exit(1);
}
int main()
{
    signal(SIGSEGV,handler);
    int* p = nullptr;
    *p = 100;//野指针问题
    cout<<"野指针问题..."<<endl;
}

*p=100,第一步并不是写入，而是首先进行虚拟到物理地址的转换

1. 没有映射，MMU硬件报错
2. 有映射，但是没有权限，MMU直接报错

由此我们可以确认，我们在C/C++当中除0，内存越界等异常，在系统层面，是被当成信号处理的。
总结

• 上面所说的所有信号产生，最终都要有OS来进行执行，为什么？OS是进程的管理者
• 信号的处理是否是立即处理的？在合适的时候
• 信号如果不是被立即处理，那么信号是否需要暂时被进程记录下来？记录在哪里最合适呢？是的；记录在PCB中
• 一个进程在没有收到信号的时候，能否能知道，自己应该对合法信号做何处理呢？知道，每一个信号对应一个value，对应一种默认方法

Linux系统提供了一种能力，可以将一个进程在异常的时候，OS可以将该进程在异常的时候，核心代码部分进行核心转储，将内存中进程的相关数据，全部dump到磁盘中，一般会在当前进程的运行目录下，形成core.pid（核心转储文件）这样的二进制文件。

云服务器将核心转储文件大小默认设置为0，这里我们使用ulimit -c 调整文件大小为1024

接下来编写程序，然后运行程序，向当前进程发送Action为core的信号。在这里我发送的是8号信号。

#include
#include
#include


using namespace std;

int main()
{
    while(true)
    {
        cout<<"我正在模拟进程异常..."<<getpid()<<endl;
        sleep(1);

    }
    return 0;
}

可以看到通过向进程发送8号信号之后，进程被终止，同时生成了core.pid的这样一个文件，打开文件里面全是乱码。

• 既然core也可以终止程序，那么和Term有什么不同呢？
  Term：就是终止，没有多余的动作
  Core：终止，会先进行核心转储，然后再终止进程。
• 核心转储有什么用呢？
  方便异常后，进行调试

我们先人为制造一些错误

#include
#include
#include
using namespace std;
int main()
{
    int *p = nullptr;
    *p=100;
    cout<<"野指针问题..."<<endl;
}

• 为什么云服务器默认关闭核心转储这个功能？
  可以看到我们的core文件占比很大，甚至比我们的源程序还大。云服务器作为一款已经上线的服务，可能由于使用者使用不当，有大量的进程可能会出现bug，这时如果可以产生core文件，那么大量的core文件会占据我们大量的空间。
  

#include
#include
#include
#include
#include


using namespace std;

int main()
{
    sleep(2);
    pid_t id = fork();
    //子进程
    if(id == 0)
    {
        cout << "野指针问题..." << endl;
        cout << "野指针问题..." << endl;
        cout << "野指针问题..." << endl;

        int *p = nullptr;
        *p = 100; // 野指针问题

        cout << "野指针问题..." << endl;
        cout << "野指针问题..." << endl;
        cout << "野指针问题..." << endl;
        exit(0);
    }
    int status = 0;
    waitpid(id,&status,0);
    cout<<"exit code:"<<(((status)>>8)&0xFF)<<endl;
    cout<<"exit signal:"<<(status&0x7F)<<endl;
    cout<<"core dump flag:"<<((status>>7)&0x1)<<endl;
}

运行结果：

3.保存信号

阻塞信号

信号其他相关常见概念

• 实际执行信号的处理动作称为信号递达（Delivery）
• 信号从产生到递达之间的状态，称为信号未决（Pending）
• 进程可以选择阻塞（Block）某个信号
• 被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞，才执行递达的动作
• 注意，阻塞和忽略是不同的，只要信号被阻塞就不会递达，而忽略是在递达之后可选的一种处理动作。

在内核中的表示

• pendding 表：位图结构。比特位的位置，表示哪一个信号；比特位的内容，代表是否收到该信号。
• block 表：位图结构。比特位的位置，表示哪一个信号；比特位的内容，代表是否屏蔽该信号（对应信号是否被阻塞）
• handler 表 ：函数指针数组 void(*sighandler_t[])(int).该数组的下标表示信号编号；数组的特定下标的内容，表示该信号的递达动作

每个信号都有两个标志位分别表示阻塞（block）和未决（pendding），还有一个函数指针表示处理动作。信号产生时，内核在进程控制块中设置该信号的未决标志，直到信号递达才清除该标志。在上图的例子中，SIGUP信号未阻塞也未产生过，当它递达时执行默认处理动作。
SIGINT信号产生过，但正在被阻塞，所以暂时不能递达。虽然它的处理动作是忽略，但在没有解除阻塞之前不能忽略这个信号，因为进程仍有机会改变处理动作之后再解除阻塞。
SIGQUIT信号未产生过，一旦产生SIGQUIT信号江北阻塞，它的处理动作是用户自定义函数sighandler。如果再进策划功能解除对某信号的阻塞之前这种信号产生过多次，将如何处理？POSIX.1允许系统递送该信号一次或多次。Linux是这样实现的：常规信号在递达之前产生过多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里。

sigset_t

从上图来看，每个信号只有一个bit的未决标志，非0即1，不记录该信号产生了多少次，阻塞标志也是这样表示的。因此，未决和阻塞标志可以用相同的数据类型，sigset_t来存储，sigset_t称为信号集，这个类型可以表示每个信号的“有效”或“无效”状态，在阻塞信号集中“有效”和“无效”的含义是否被阻塞，而在未决信号集中“有效”和“无效”的含义是该信号是否处于未决状态、阻塞信号集也叫做当前进程的信号屏蔽字（Signal Mask），这里的“屏蔽”应该理解为阻塞而不是忽略。

信号集操作函数

sigset_t类型对于每种信号用一个bit表示“有效”或者“无效”状态，至于这个类型内部如何存储这些bit则依赖于系统实现，从使用者的角度是不必关心的，使用者只能调用以下函数来操作sigset_t变量，而不应该对它的内部数据做任何解释，比如用printf直接打印sigset_t变量是没有意义的。

#include
int sigemptyset(sigset_t *set);
int sigfillset(sigset_t *set);
int sigaddset(sigset_t *set);
int sigdelset(sigset_t *set,int signo);
int sigismember(const sigset_t *set,int signo);
//成功返回0，出错返回-1，
//sigismember是一个布尔函数，包含返回1，不包含返回0，出错返回-1

注：在使用sigset_t类型的变量之前，一定要调用sigemptyset或sigfillset做初始化，使信号集处于确定的状态，初始化sigset_t变量之后就可以在调用sigaddset和sigdelset在该信号集中添加或删除某种有效信号

sigprocmask
调用函数sigprocmask可以读取或更改进程的信号屏蔽字（阻塞信号集）。

#include
int sigprocmask(int how,const sigset_t *set,sigset_t *oset);
//成功返回0，出错返回-1

• 如果set为空指针，oset是非空指针，则读取进程的当前信号屏蔽字通过oset参数传出
• 如果set是非空指针，oset为空指针，则更改进程的信号屏蔽字，参数how指示如何更改。
• 如果set和oset都是非空指针，则先将原来的信号屏蔽字备份到oset里，然后根据set和how更改信号屏蔽字。假设当前的信号屏蔽字为mask，下表说明了how参数的可选值。

how可选参数	解释
SIG_BLOCK	set包含了我们希望添加到当前信号屏蔽字的信号，相当于mask=mask
SIG_UNBLOCK	set包含了我们希望从当前信号屏蔽字中解除阻塞的信号，相当于mask=mask&~set
SIG_SETMASK	设置当前信号屏蔽字为set所指向的值，相当于mask=set

如果调用sigprocmask解除了对当前若干个未决信号的阻塞，则在sigprocmask返回前，至少将其中一个信号递达。

下面我们来看一段代码

#include
#include
#include
#include

using namespace std;

static void handler(int signo)
{
    cout<<"对特定信号"<<signo<<"执行捕捉动作"<<endl;
}
static void PrintPending(const sigset_t &pending)
{
    cout<<"当前进程的pending位图"<<endl;
    for(int signo=1;signo<=31;signo++)
    {
        if(sigismember(&pending,signo)) cout<<"1";
        else cout<<"0";
    }
    cout<<"\n";
}
int main()
{
    //1.屏蔽2号信号
    sigset_t set,oset;
    //1.1初始化
    sigemptyset(&set);
    sigemptyset(&oset);

    //1.2将2号信号添加到set中
    sigaddset(&set,SIGINT);//2号信号

    //1.3将新的信号屏蔽字设置进程
    sigprocmask(SIG_BLOCK,&set,&oset);

    // 设置对2号信号的捕捉
    signal(2,handler);
    //2.while获取进程的pending信号集合，并01打印
    int cnt = 0;
    while(true)
    {

        //2.1 先获取pending信号集
        sigset_t pending;
        sigemptyset(&pending);//不是必须的
        int n = sigpending(&pending);
        assert(n==0);
        (void)n;//保证不会出现编译时的warning

        //2.2打印
        PrintPending(pending);


        //2.3休眠一下
        sleep(1);
        
        //2.4 10s之后，恢复对所有信号的block动作
        if(cnt++==10)
        {
            cout<<"解除对2号信号的屏蔽"<<endl;
            sigprocmask(SIG_SETMASK,&oset,nullptr);
        }     
    } 
}

运行结果：

信号可以被立即处理吗？如果一个信号之前被block了，当他被解除block的时候，对应的信号会被立即递达。

为什么？信号的产生是异步的，当前进程可能正在做更重要的事情。什么是合适的时候呢？当进程从内核态切换回用户态的时候，会在OS指导下，进行信号的检测与处理！

用户态：执行你写的代码的时候，进程所处的状态。
内核态：执行OS的代码的时候，进程所处的状态。
常见从用户态转换为内核态的情况有：
1、进程时间片到了
2、系统调用

1. 所有的进程【0,3】DB是不一样的，每一个进程都要有自己的用户级页表
2. 所有的进程[3,4]GB是一样的，每一个进程都可以看到同一张内核级页表，所有进程都可以通过统一的窗口，看到同一个OS！
3. OS运行的本质，其实都是在进程的地址空间内运行的。
   无论进程如何切换，[3,4]GB里面的内容不变。看到OS的内容与进程的切换无关。
4. 所谓的系统调用的本质：其实就如同调用OS的方法，在自己的地址空间中进行函数跳转并返回。
5. OS的本质：os是软件，本质是一个死循环；OS时钟硬件，每隔很近的时间向OS发送时钟中断。OS监测当前进程的时间片，执行对应的中断处理方法。

4、捕捉信号

---

1、内核如何实现信号的捕捉
如果信号的处理动作时用户自定义函数，在信号递达时就调用了这个函数，这称为捕捉信号。由于信号处理函数的代码是在用户空间的，处理过程比较复杂，举例如下：用户程序注册了SIGQUIT信号的处理函数myhandler。当前正在执行main函数，这时发生中断或异常切换到内核态。在中断处理完毕后要返回用户态的main函数之前检查到有信号SIGQUIT递达。内核决定返回用户态后不是恢复main函数的上下文继续执行，而是执行myhandler函数，myhandler函数和main函数使用不同的堆栈空间，他们之间不存在调用和被调用的关系，而是两个独立的控制流程。myhandler函数返回后自动执行特殊的系统调用sigreturn再次进入内核态。如果没有新的信号要递达，这次再返回用户态就是恢复main函数的上下文继续执行了。
2、sigaction

#include

int sigaction(int signo,const struct sigaction *act,const struct sigaction *oldact);

• sigaction函数可以读取和修改与指定信号相关联的处理动作。调用成功就返回0，调用失败就返回-1。signo是指定信号的编号。若act指针非空，则根据act修改该信号的处理动作。若oact指针非空，则通过oact传出该信号原来的处理动作。act和oact指向sigaction结构体。
• 将sa_handler赋值为常数SIG_IGN传给sigactionn表示忽略信号，赋值为常数SIG_DEL表示执行系统默认动作，赋值为一个函数指针表示用自定义函数捕捉信号，或者说向内核注册了一个新年好处理函数，该函数返回值为void，可以带一个int参数，通过参数可以得知当前信号的编号，这样就可以用同一个函数处理多种信号。显然，这也是一个回调函数，不是被main函数调用，而是被系统所调用。
  当某个信号的处理函数被调用时，北河自动将当前信号加入进程的信号屏蔽字，当信号处理函数返回时，自动恢复原来的信号屏蔽字，这呀就保证了在处理某个信号时，如果这种信号再次产生，那么他会被阻塞到当前处理结束为止。如果在调用信号处理函数时，除了当前信号被自动屏蔽之外，还希望自动屏蔽另外一些信号，则用sa_mask字段说明这些需要额外屏蔽的信号，当信号处理函数返回时自动恢复原来的信号屏蔽字。

看以下代码：

#include
#include
#include
#include
#include
using namespace std;

static void PrintPending(const sigset_t &pending)
{
    cout<<"当前进程的pending位图:";
    for(int signo=1;signo<=31;signo++)
    {
        if(sigismember(&pending,signo)) cout<<"1";
        else cout<<"0";
    }
    cout<<"\n";
}
static void handler(int signo)
{
    cout<<"对特定信号"<<signo<<"执行捕捉动作"<<endl;
    int cnt = 30;
    while(cnt)
    {
        cnt--;
        sigset_t  pending;
        sigpending(&pending);
        PrintPending(pending);
        sleep(1);
    }
}

int main()
{
    struct sigaction act,oldact;
    memset(&act,0,sizeof(act));
    memset(&oldact,0,sizeof(oldact));

    act.sa_handler = handler;
    act.sa_flags=0;

    sigemptyset(&act.sa_mask);

    sigaddset(&act.sa_mask,3);
    sigaddset(&act.sa_mask,4);
    sigaddset(&act.sa_mask,5);

    sigaction(2,&act,&oldact);
    while(true)
    {
        cout<<getpid()<<endl;
        sleep(1);

    }
}
// If act is non-NULL, the new action for signal signum is installed from act.  If oldact is non-NULL, the previous  action is saved in oldact.

我们在对2号信号进行捕捉时，希望对3、4、5号信号进行屏蔽，那么就可以使用sigaddset(&act.sa_mask,signo)。
可重入函数

• main函数调用insert函数向一个链表head中插入节点node1,插入操作分为两步,刚做完第一步的 时候,因
  为硬件中断使进程切换到内核,再次回用户态之前检查到有信号待处理,于是切换 到sighandler函
  数,sighandler也调用insert函数向同一个链表head中插入节点node2,插入操作的 两步都做完之后从
  sighandler返回内核态,再次回到用户态就从main函数调用的insert函数中继续 往下执行,先前做第一步
  之后被打断,现在继续做完第二步。结果是,main函数和sighandler先后 向链表中插入两个节点,而最后只
  有一个节点真正插入链表中了。
• 像上例这样,insert函数被不同的控制流程调用,有可能在第一次调用还没返回时就再次进入该函数,这称
  为重入,insert函数访问一个全局链表,有可能因为重入而造成错乱,像这样的函数称为 不可重入函数,反之,
  如果一个函数只访问自己的局部变量或参数,则称为可重入(Reentrant) 函数。想一下,为什么两个不同的
  控制流程调用同一个函数,访问它的同一个局部变量或参数就不会造成错乱?
  **如果一个函数符合以下条件之一则是不可重入的：
• 调用了malloc或free，因为malloc也是用全局链表来管理堆的。
• 调用了标准I/O库函数。标准I/O库的很多实现都以不可重入的方式使用全局数据结构。

volatile
看下面一段代码:

#include
#include
int quit = 0;

void handler(int signo)
{
    printf("change quit from 0 to 1\n");
    quit = 1;
}
int main()
{
    signal(2,handler);
    while(!quit);//注意这里我们故意没有携带while的代码快，故意让编译器认为在main中，quit只会被检测
    
    printf("main quit 正常\n");
    return 0;
}

运行结果：

添加gcc 选项 -O2之后运行结果为：

我们在handler函数里面添加一点验证的代码

可以看到quit的值确实不一样，可以推测是由于编译器优化。本来每一次读取quit的值的时候，应该去内存中拿，但是编译器却仿佛是就近就从CPU中的寄存器里面取了。所以现在我们需要做的就是，告诉编译器，保证每次检测，都要尝试从内存中进行数据读取，不要用寄存器中的数据，让内存数据可见

所以这个时候volatile就出现了。

#include
#include
#include
#include
#include

pid_t id;
void handler(int signo)
{
    printf("捕捉到一个信号：%d,who:%d\n",signo,getpid());
    sleep(5); 

    pid_t res =  waitpid(-1,NULL,0);
    if(res > 0)
    {
        printf("wait success,res:%d,id:%d\n",res,id);
    }
}
int main()
{
    signal(SIGCHLD,handler);
    id = fork();
    if(id == 0)
    {
        //child
        int cnt = 5;
        while(cnt)
        {
            printf("我是子进程，我的pid:%d ;ppid:%d\n",getpid(),getppid());
            sleep(1);
            cnt--;
        }
        exit(1);
    }
    while(1)
    {
        sleep(1);

    }
}

运行结果：

分析：

SIGCHLD信号
wait和waitpid函数清理僵尸进程,父进程可以阻塞等待子进程结束,也可以非阻 塞地查询是否有子进程结束等待清理(也就是轮询的方式)。采用第一种方式,父进程阻塞了就不 能处理自己的工作了;采用第二种方式,父进程在处理自己的工作的同时还要记得时不时地轮询一 下,程序实现复杂。

其实,子进程在终止时会给父进程发SIGCHLD信号,该信号的默认处理动作是忽略,父进程可以自 定义SIGCHLD信号
的处理函数,这样父进程只需专心处理自己的工作,不必关心子进程了,子进程 终止时会通知父进程,父进程在信号处理
函数中调用wait清理子进程即可

#include
#include
#include
#include
#include
#include

pid_t id;
void handler(int signo)
{
    printf("捕捉到一个信号：%d,who:%d\n",signo,getpid());
    sleep(5); 

    while(1)
    {
        pid_t res =  waitpid(-1,NULL,WNOHANG);
        if(res > 0)
        {
            printf("wait success,res:%d,id:%d\n",res,id);
        }
        else break;
    }
    printf("handler done ...\n");
}
int main()
{
    signal(SIGCHLD,handler);
    for(int i = 0;i<=10;i++)
    {
        //child
        id = fork();
        int cnt = 5;
        while(cnt)
        {
            printf("我是子进程，我的pid:%d ;ppid:%d\n",getpid(),getppid());
            sleep(1);
            cnt--;
        }
        exit(1);
    }
    while(1)
    {
        sleep(1);
        printf("我是父进程，我正在运行\n");

    }
}

事实上,由于UNIX 的历史原因,要想不产生僵尸进程还有另外一种办法:父进程调 用sigaction将SIGCHLD的处理动作置为SIG_IGN,这样fork出来的子进程在终止时会自动清理掉,不 会产生僵尸进程,也不会通知父进程。系统默认的忽略动作和用户用sigaction函数自定义的忽略 通常是没有区别的,但这是一个特例。此方法对于Linux可用,但不保证在其它UNIX系统上都可 用。

#include
#include
#include
#include
#include
#include

pid_t id;
int main()
{
    signal(SIGCHLD,SIG_IGN);
    for(int i = 0;i<=10;i++)
    {
        //child
        id = fork();
        int cnt = 5;
        while(cnt)
        {
            printf("我是子进程，我的pid:%d ;ppid:%d\n",getpid(),getppid());
            sleep(1);
            cnt--;
        }
        exit(1);
    }
    while(1)
    {
        sleep(1);
        printf("我是父进程，我正在运行\n");

    }
}