信号
1.信号入门
- 程序员设计进程的时候，早就已经设计了对信号的识别能力！！！！
- 进程在没有收到信号的时候，其实它早就已经知道一个信号该怎么处理了！
- 因为信号可能随时会产生，所有在信号产生前，我可能正在做优先级更高的事情，我可能不能立马处理这个信号！我们要在合适的时候进行处理，同理进程收到信号的时候，如果没有立马处理这个信号，就需要进程具有记录信号的能力！
- 信号的产生对于进程来说是异步的
- 进程先描述在组织对应产生的信号，并使用位图这一个数据结构进行记录
- 所谓的发送信号，本质其实是写入信号。直接修改特定进程的信号位图中的特定比特位。(0->1)
- task_struct 属于内核数据结构，只能由OS进行修改–无论后面有多少种信号产生的方式，最终都必须让OS来完成最后的发送过程！
- 信号产生之后，不是立即处理的，是在合适的时候。
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以上的是实时信号，我们暂时不讨论
处理信号的方式：
- 默认动作
- 忽略信号
- 用户自定义行为
2.产生信号
下面来看一段简单的代码，我们通过实例来看进程产生信号的方式
Makefile
mysignal:mysignal.cc
g++ -o $@ $^ -std=c++11
.PHONY:clean
clean:
rm -f mysignal
mysignal.cc
#include<iostream>
#include<unistd.h>
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<iostream>
#include<unistd.h>
#include<signal.h>
//自定义方法
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<iostream>
#include<unistd.h>
#include<signal.h>
//自定义方法
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<iostream>
#include<unistd.h>
#include<assert.h>
#include<signal.h>
#include<cstring>
#include<sys/types.h>
#include<cerrno>
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<iostream>
#include<unistd.h>
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 <signal.h>
int kill(pid_t pid, int signo);
int raise(int signo);
这两个函数都是成功返回0,错误返回-1。
abort
使当前进程接受到信号而异常终止
#include <stdlib.h>
void abort(void);
就像exit函数一样,abort函数总是会成功的,所以没有返回值。
mykill.cc
#include<iostream>
#include<unistd.h>
#include<assert.h>
#include<signal.h>
#include<cstring>
#include<sys/types.h>
#include<cerrno>
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<iostream>
#include<unistd.h>
#include<assert.h>
#include<signal.h>
#include<cstring>
#include<sys/types.h>
#include<cerrno>
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<iostream>
#include<unistd.h>
#include<assert.h>
#include<signal.h>
#include<cstring>
#include<sys/types.h>
#include<cerrno>
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<<std::endl;
count++;
}
4.硬件异常产生信号
硬件异常被硬件以某种方式被硬件检测到并通知内核，然后内核向当前进程发送适当的信号。例如当前进程执行了除0以外的指令，CPU的运算单元会产生异常，内核将这个异常解释为SIGFPE信号发送给进程。再比如当前进程访问了非法内存地址，MMU会产生异常，内核将这个异常解释为SIGSEGV信号发送给进程。
除0错误
除0的本质就是触发硬件异常（CPU）
mysignal.cc
#include<iostream>
#include<signal.h>
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<iostream>
#include<signal.h>
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<iostream>
#include<signal.h>
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,第一步并不是写入，而是首先进行虚拟到物理地址的转换
- 没有映射，MMU硬件报错
- 有映射，但是没有权限，MMU直接报错
由此我们可以确认，我们在C/C++当中除0，内存越界等异常，在系统层面，是被当成信号处理的。
总结
- 上面所说的所有信号产生，最终都要有OS来进行执行，为什么？OS是进程的管理者
- 信号的处理是否是立即处理的？在合适的时候
- 信号如果不是被立即处理，那么信号是否需要暂时被进程记录下来？记录在哪里最合适呢？是的；记录在PCB中
- 一个进程在没有收到信号的时候，能否能知道，自己应该对合法信号做何处理呢？知道，每一个信号对应一个value，对应一种默认方法
Linux系统提供了一种能力，可以将一个进程在异常的时候，OS可以将该进程在异常的时候，核心代码部分进行核心转储，将内存中进程的相关数据，全部dump到磁盘中，一般会在当前进程的运行目录下，形成core.pid（核心转储文件）这样的二进制文件。
云服务器将核心转储文件大小默认设置为0，这里我们使用ulimit -c 调整文件大小为1024
接下来编写程序，然后运行程序，向当前进程发送Action为core的信号。在这里我发送的是8号信号。
#include<iostream>
#include<signal.h>
#include<unistd.h>
using namespace std;
int main()
{
while(true)
{
cout<<"我正在模拟进程异常..."<<getpid()<<endl;
sleep(1);
}
return 0;
}
可以看到通过向进程发送8号信号之后，进程被终止，同时生成了core.pid的这样一个文件，打开文件里面全是乱码。
- 既然core也可以终止程序，那么和Term有什么不同呢？
Term：就是终止，没有多余的动作
Core：终止，会先进行核心转储，然后再终止进程。 - 核心转储有什么用呢？
方便异常后，进行调试
我们先人为制造一些错误
#include<iostream> #include<signal.h> #include<unistd.h> using namespace std; int main() { int *p = nullptr; *p=100; cout<<"野指针问题..."<<endl; }
- 为什么云服务器默认关闭核心转储这个功能？
可以看到我们的core文件占比很大，甚至比我们的源程序还大。云服务器作为一款已经上线的服务，可能由于使用者使用不当，有大量的进程可能会出现bug，这时如果可以产生core文件，那么大量的core文件会占据我们大量的空间。
#include<iostream>
#include<signal.h>
#include<unistd.h>
#include<sys/types.h>
#include<sys/wait.h>
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<signal.h>
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<signal.h>
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<iostream>
#include<signal.h>
#include<cassert>
#include<unistd.h>
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、系统调用
- 所有的进程【0,3】DB是不一样的，每一个进程都要有自己的用户级页表
- 所有的进程[3,4]GB是一样的，每一个进程都可以看到同一张内核级页表，所有进程都可以通过统一的窗口，看到同一个OS！
- OS运行的本质，其实都是在进程的地址空间内运行的。
无论进程如何切换，[3,4]GB里面的内容不变。看到OS的内容与进程的切换无关。 - 所谓的系统调用的本质：其实就如同调用OS的方法，在自己的地址空间中进行函数跳转并返回。
- OS的本质：os是软件，本质是一个死循环；OS时钟硬件，每隔很近的时间向OS发送时钟中断。OS监测当前进程的时间片，执行对应的中断处理方法。
4、捕捉信号
1、内核如何实现信号的捕捉
如果信号的处理动作时用户自定义函数，在信号递达时就调用了这个函数，这称为捕捉信号。由于信号处理函数的代码是在用户空间的，处理过程比较复杂，举例如下：用户程序注册了SIGQUIT信号的处理函数myhandler。当前正在执行main函数，这时发生中断或异常切换到内核态。在中断处理完毕后要返回用户态的main函数之前检查到有信号SIGQUIT递达。内核决定返回用户态后不是恢复main函数的上下文继续执行，而是执行myhandler函数，myhandler函数和main函数使用不同的堆栈空间，他们之间不存在调用和被调用的关系，而是两个独立的控制流程。myhandler函数返回后自动执行特殊的系统调用sigreturn再次进入内核态。如果没有新的信号要递达，这次再返回用户态就是恢复main函数的上下文继续执行了。
2、sigaction
#include<signal.h>
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<iostream>
#include<signal.h>
#include<cassert>
#include<unistd.h>
#include<cstring>
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<stdio.h>
#include<signal.h>
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<stdio.h>
#include<signal.h>
#include<unistd.h>
#include<sys/types.h>
#include<stdlib.h>
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<stdio.h>
#include<signal.h>
#include<unistd.h>
#include<sys/types.h>
#include<stdlib.h>
#include<sys/wait.h>
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<stdio.h>
#include<signal.h>
#include<unistd.h>
#include<sys/types.h>
#include<stdlib.h>
#include<sys/wait.h>
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");
}
}
3759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
