信号
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");
}
}