Signal主要分两大部分:
A. 什么是Signal,有哪些Signal,都是干什么使的。
B. 列举了非常多不正确(不可靠)的处理Signal的方式,以及怎么样设计来避免这些错误出现。
10.2 Signal Concepts
1. Signal的实体就是在头文件中定义的正整数(在我使用的linux系统中在/usr/include/bits/signum.h中),如下:
2. 列举了可能会产生Signal的条件:
(1)终端的user的案件操作:如,Ctrl+c,Ctrl+\;由terminal发出。
(2)硬件异常抛出的Signal:如,除0,非法内存引用;由kernel发出。
(3)kill(2) kill(1) :向process或process group发送Signal;由process发出。
(4)软件执行时产生的Signal :比如后面要提到的SIGALRM,定点到时信号。
3. Signal是典型的异步驱动时事件,当Signal出现的时候,可以设定程序来告知kernal去做什么事情:
(1)忽略Signal。这里有两个Signal不能忽略:分别是SIGKILL和SIGSTOP。不能忽略的原因是必须让kernal或root权限可以强制终止进程。如果遇到了hardware exception情况,不去处理这类异常的话,进程后续如何执行就不确定了。
(2)捕获Signal。这里的做法是预先告诉kernal“如果出现了这个信号,用哪个函数去处理”。另,SIGKILL和SIGSTOP是不能被捕获的。
(3)默认处理策略。系统预先指定了几个Signal默认的处理策略。在signum.h中:
具体可以对照Figure10.1中每个Signal的默认处理策略去查看;有些默认策略是terminal+core类型的,可用于系统down了之后的debug。但是,也不一定保证core一定会产生;如果权限不足的话,很可能无法产生core。这个也要留意。
4. 这里插播一个Signal的解释。SIGTSTP,当执行终端命令交互的程序到时候,按下ctrl+z可以触发这个信号,向foreground process group所有的。这个信号名字里虽然叫stop,但是并不是真的给停了。这里与stop相对的是continue(即SIGCONT),只是给暂停的意思。这个信号如果只是望文生义,就容易理解偏差。不仅仅是这个信号,后面还有更无法望文生义的名词解释。
10.3 signal function
signal这个函数的含义就是告诉系统用什么函数处理什么信号。
1. 看一个例子:
1 #include "apue.h" 2 #include <stdio.h> 3 #include <signal.h> 4 5 static void sig_usr(int signo) 6 { 7 if (signo==SIGUSR1) 8 { 9 printf("received SIGUSR1\n"); 10 } 11 else if (signo==SIGUSR2) 12 { 13 printf("received SIGUSR2\n"); 14 } 15 else 16 { 17 } 18 } 19 20 int main(void) 21 { 22 if (signal(SIGUSR1, sig_usr) == SIG_ERR) 23 { 24 err_sys("can't catch SIGUSR1"); 25 } 26 if (signal(SIGUSR2, sig_usr) == SIG_ERR) 27 { 28 err_sys("can't catch SIGUSR2"); 29 } 30 for (;;) 31 { 32 pause(); 33 } 34 }
执行结果如下:
初步分析如下:
(1)main中给SIGUSR1和SIGUSR2都注册了signal handler
(2)pause()函数的作用是阻塞进程,并一直等着signal到来。
(3)kill跟它叫kill没有关系,纯粹是unix系统的一个misnomer,它的作用就是向process或process group发送信号。因此就是发送SIGUSR1和SIGUSR2信号。
(4)kill默认情况下发送的信号是SIGTERM,即终止进程。
如果连续两次发送SIGUSR1信号会怎样?如下:
通过上面的运行结果可知,用signal给某个信号注册一次handler,只能管一次。即,在信号发生跳转到自定的 handler 处理函数执行后, 系统会自动将此处理函数换回原来系统预设的处理方式。那么有没有注册一次,能够处理多次信号的方法呢?有,改用sigaction函数去注册signal handler。代码如下:
1 #include "apue.h" 2 #include <stdio.h> 3 #include <signal.h> 4 5 static void sig_usr(int signo) 6 { 7 if (signo==SIGUSR1) 8 { 9 printf("received SIGUSR1\n"); 10 } 11 else if (signo==SIGUSR2) 12 { 13 printf("received SIGUSR2\n"); 14 } 15 else 16 { 17 } 18 } 19 20 int main(void) 21 { 22 struct sigaction sa1, sa2; 23 sa1.sa_handler = sig_usr; 24 sa2.sa_handler = sig_usr; 25 sigemptyset(&sa1.sa_mask); 26 sigemptyset(&sa2.sa_mask); 27 sigaddset(&sa1.sa_mask, SIGUSR1); 28 sigaddset(&sa2.sa_mask, SIGUSR2); 29 sigaction(SIGUSR1, &sa1, NULL); 30 sigaction(SIGUSR2, &sa2, NULL); 31 /* 32 if (signal(SIGUSR1, sig_usr) == SIG_ERR) 33 { 34 err_sys("can't catch SIGUSR1"); 35 } 36 if (signal(SIGUSR2, sig_usr) == SIG_ERR) 37 { 38 err_sys("can't catch SIGUSR2"); 39 } 40 */ 41 for (;;) pause(); 42 }
运行结果如下:
Program Start-Up :
这里面提到了一种情况,如果是由某个程序通过执行exec产生的新的Program,进而替代原来的Process(虽然进程号不变,但是即使是执行原来的程序,程序的地址也变化了);那么,由原来的Porcess注册的各种Signal处理相关的内容,在新的Program中是无效的,因为原来的signal-handler中注册的信号处理函数的地址失效了,不是原来的函数了。
从下面的部分开始,更多的从反面出发,分析signal处理上经历的各种不靠谱设计,从而理解为什么要设计各种靠谱的机制。
10.4 Unreliable Signals
1. 不靠谱伪代码(1):
int sig_int(); /*signal处理函数*/ ... signal(SIGINT, sig_int); /*注册signal handler*/ ... sig_int() { signal(SIGINT, sig_int); /*重新注册signal handler以便处理下一次信号*/ ... }
了解过signal函数之后,可以知道,上述代码的意思大概是:每次出现SIGINT信号,都会触发sig_int()函数来处理信号;由于signal函数只能管处理一次SIGINT,因此为了能够连续处理SIGINT信号,在每次进入sig_int()函数时,都重新用signal函数注册一下sig_int。
上面的代码看似是没有问题的,但是却隐含着比较大的漏洞。
考虑如下的情况:如果之前已经来了一个SIGINT信号,系统开始调用注册的sig_int()进行信号处理;如果恰恰在进入sig_int()函数之前,又来了一个SIGINT信号;由于此时系统已经没有用于处理SIGINT信号的函数了,则第二个到来的SIGINT信号就被采用默认的信号处理策略(对于SIGINT这个信号来说,就是直接将进程terminates了),往往达不到我们预期的信号处理效果。这种漏洞的可怕之处还在于,大部分时间程序都是工作正确的,偶尔会出现问题,这种bug是最难排除的。
2. 不靠谱伪代码(2):
int sig_int(); /*SIGINT信号处理函数*/ int sig_int_flag; /*SIGINT信号出现时候将其赋值为零*/ main() { signal(SIGINT, sig_int); /*注册信号处理函数*/ ... while(sig_int_flay == 0) { pause(); /*等着信号到来*/ } } sig_int() { signal(SIGINT, sig_int); /*重新注册信号处理函数*/ sig_int_flag = 1; /*修改环境变量*/ }
上述的伪代码的本意是:main函数中的while循环就要等着SIGINT信号的到来,并且处理完sig_int_flag标志标量,才往下进行。
代码的本意是好的,但是还是存在漏洞。
考虑如下的情况:如果已经注册完了sig_int函数,首次进入while循环的判断条件,变量为0;而恰恰在执行while循环体中的pause()之前,来了一个SIGINT信号;开始执行sig_int的过程中已经把sig_int_flag设置为1了;sig_int执行完毕,开始执行pause()函数;如果以后再也不来SIGINT信号了,那么pause()就一直等下去了。还是跟上一个不靠谱的代码问题一样,这样的代码大部分时间可以正常运行,偶尔出现问题,非常难debug。
总结一下上面两个不靠谱的代码,其核心问题我认为是:signal是异步出现的,随时都能打断当前执行的程序;而上述代码的设计思路都是传统的同步顺序执行的,所以会遇到各种细节问题:
(1)第一种情况是signal“该来的时候来了,不该来的时候也来了”,即信号处理函数失效。
(2)第二种情况是signal“该来的时候不来,不该来的时候也来了”,即信号丢失。
10.5 Interrupted System Calls
这个部分阐述与System Call相关的signal处理问题。我没太理解深入,暂时记录以下两点:
(1)早期的unix系统中,如果某个process正在被“a slow system call”给阻塞;那么这个时候来个信号,原来正在执行的“a slow system call”就被打断了,返回一个error并且errno被设置为EINTR。
(2)为了避免这样的问题,有的系统提供了处理上述问题的system call restart的机制。可能的做法就是每次执行slow system call的时候,都去检查error的返回值,是否是EINTR,来决定是否启动restart。
有个伪代码如下:
again: if ( (n = read(fd, buf, BUFFSIZE)) < 0 ) { if ( error == EINTR ) goto again; /*被interrupted的system call*/ ... /*处理其他问题*/ }
在后续的14.4节中,select()和poll()函数的时候还会细说interrupted system calls
10.6 Reentrant Functions (可重入函数)
这部分说的是signal处理中安全问题,是否可重入。(可以查阅这个bloghttp://particle128.com/posts/2014/05/reentrant.html)
所谓的安全问题,是指signal到来与处理,打断了原来执行的程序;在执行完信号处理函数后,原来正在执行的程序可能就受到影响了,与预想的结果不太一样,这就是我理解的signal安全。
书上举了两个例子,来说明由于重入某些函数可能带来的signal不安全情况:
(1)如果原进程正执行malloc分配内存呢,分配到一半的时候来个signal信号;然后进入到信号处理函数中,又用到malloc函数动态分配内存了。
(2)如果原进程正执行getpwnam函数呢(简单理解getpwnam往一个static的存数据),正执行到一半突然来个signal信号;然后进入到signal信号处理函数中,又调用getpwnam;结果就是上次存一半的结果被新的覆盖了;再次回到原来的进程顺序执行的时候,getpwnam获得结果就乱套了。
上述的例子只是一个热身,系统些来说,判断一个signal handler函数是不是reentrant的,一般从signal handler function如下的几个方面进行考虑:
(1)是否用到了static data:如果信号发生时正调用getwpnam,并且在signal handler中也调用了getwpnam,则在handler中新获取的值就会覆盖之前进程中获取的值。
(2)是否调用了free或者malloc函数:如果信号发生时正调用malloc(修改堆上的存储空间连接表),并且信号处理程序又调用malloc,会破坏内核的数据结构。
(3)是否调用了standard IO:因为好多standard I/O函数都使用了全局的数据结构(如,printf中用到的文件偏移量是全局的)
(4)是否用了longjmp这类的函数:信号发生时候程序正在修改一个数据结构,longjmp这种完全推倒重来的函数在信号处理中一旦出现,就容易出现改一半就没改完的情况
类unix系统中,如果对于signal是安全的,有两种要求:
(1)首先函数必须是reentrant fucntion标准的(上述的4点),即从自身设计上不要出现signal不安全的漏洞
(2)这些函数执行时已经block各类signal,即从外部影响上主动避开signal出现带来的问题
另外,书上还提醒了一点:即使是调用Figure10.4中的reentrant function,还需要检验errno这个变量值;原因是,可能在信号处理函数中改变了error的实际值。比如,如果信号处理函数中调用了read(参考interrupted system call的内容),就有可能在信号处理完成后改变error的值。
因此,即使在signal handler中调用的是Figure10.4中的reentrant function,也需要在信号处理函数中检验errno的值。
例如,在Figure10.4中有fork函数,它的作用是分叉产生一个child process;当child process执行完了之后,就会产生一个SIGCHLD信号,返回给主进程;而这个信号的signal handler一般都有一个wait function,而wait function改变errno值。
总结一下,以后再设计signal处理函数的时候,一定要注意是否是reentrant的,以及信号处理安全问题。
10.7 SIGCLD Semantics
SIGCLD和SIGCHLD都是与child process结束状态有关的信号。
这重点介绍的是SIGCLD这个信号,有一些类unix系统对于这个SIGCLD信号的处理是比较特殊的。
(1)有时候,我们不想关心一些child process的运行状况,就会把SIGCLD信号的处理方式设置为SIG_IGN。这样做的好处就是,不会产生僵尸进程,“the status of these child processes is discarded”;但是,如果父进程中不小心有wait()函数正等着这个child process,那就会一直阻塞了。
(2)如果注册signal handler来处理SIGCLD信号,在调用signal函数的时候,kernel会检测是否已经有child process正在等待被回收处理。这点特性,也带来了如下的问题。
有问题的示例代码如下:#include "apue.h#include <sys/wait.hstatic void sig_cld(int);
int main() { pid_t pid; signal(SIGCLD, sig_cld); if ( (pid=fork()) ==0 ) /*child process*/ { sleep(2); _exit(0); } pause(); exit(0); } static void sig_cld(int signo) {
int status; signal(SIGCLD, sig_cld); /*reestablish handler*/
...
pid = wait(&status); }
main()中的sleep(2)是为了保证parent process先执行pause(),然后child process再执行_exit(0)。sig_cld()函数中在开始就调用signal(SIGCLD, sig_cld)是为了能够连续处理SIGCLD信号。
不考虑其他代码漏洞,上述代码在正常逻辑顺序上有较大的问题:每次调用signal(SIGCLD, XXX)的时候,kernel就会去check是否有child process等待被回收;由于此时child process还没有被回收呢,因此kernel认为还有child process等着被处理,因此再调用sig_cld函数;整个代码陷入了循环。
总结一下,凡是涉及到SIGCLD以及SIGCHLD的信号处理问题,需要参考具体所在系统对于SIGCLD以及SIGCHLD的实现分析。
10.8 10.9 10.10 kill和alarm函数
三个部分放在一起,用一个例子综合在一起。
1. kill函数:kill(pid_t pid, int signo),向某个进程发送信号。
这里注意两点:
(1)调用kill函数的进程是否有权限给另一个进程发信号
(2)kill(pid, 0) 这种形式可以用来验证pid进程号是否存在;但是考虑到类Unix系统,即使是一个进程的资源已经释放了,进程号pid仍然会被占用一段时间,因此这种通过检测pid号的方式来检测进程是否存在也不一定是完全准确的,得看具体的系统实现。
2. alarm函数:alarm(unsigned int seconds),启动一个倒计时器,到达seconds的时间后,会触发SIGALRM的信号;如果没有设定信号处理函数,则默认的行为就是将进程结束。
这里注意两点:
(1)一个进程只能同时有一个有效的alarm函数,如果在一个进程中多次使用alarm函数:后一次的alarm时间会替代上一次的alarm的时间。具体示例如下:
#include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <sys/time.h> struct timeval start, end; void sig_int() { unsigned int seconds = 0; seconds = alarm(5); printf("left seconds: %u\n", seconds); gettimeofday(&start, NULL); pause(); } void sig_alm() { float time_interval; gettimeofday(&end, NULL); time_interval = 1000000*(end.tv_sec-start.tv_sec)+end.tv_usec-start.tv_usec; time_interval = time_interval/1000000; printf("Pasue time: %f\n", time_interval); } int main() { signal(SIGINT, sig_int); signal(SIGALRM, sig_alm); alarm(100); pause(); }
程序执行结果如图:
分析如下:main中执行倒计时100秒;大概过了10秒之后在终端ctrl+c触发interrupt信号,进入SIGINT信号处理函数;在SIGINT信号处理函数中,修改alarm的倒计时为5秒。最后从执行结果看到,第二次执行的alarm(5)替代了前一次的alarm(100)。
有时候为了避免之前设定的alarm无效了,也可以检查类似上述代码中的seconds的值,来保证等够100秒。
(2)在某些情况下,如果产生了资源竞争,调用pause()之前,alarm就执行完了,pasue()就会一直在等着了。为了避免这种情况,书上给出了如下的sleep函数的设计。我在书上代码的基础上稍加修改,为的就是在代码中更好的体现资源竞争。
#include "apue.h" #include <signal.h> #include <unistd.h> #include <setjmp.h> static jmp_buf env_alrm; static void sig_alm(int signo) { longjmp(env_alrm, 1); } unsigned int sleep2(unsigned int second) { if (signal(SIGALRM, sig_alm) == SIG_ERR){ return second; } if ( setjmp(env_alrm)==0 ) { alarm(second); kill(getpid(),SIGINT); pause(); } return alarm(0); } static void sig_int(int signo) { int i,j; volatile int k; printf("sig_int starting\n"); for ( i=0; i<300000; i++) { for (j=0; j<40000; j++) k += i*j; } printf("sig_int finished\n"); } int main() { unsigned int unslept; if (signal(SIGINT, sig_int)==SIG_ERR) { err_sys("signal(SIGINT) error"); } unslept = sleep2(5); printf("sleep2 returned : %u\n", unslept); exit(0); }
程序的执行结果如下:
分析如下:
a. 上述代码体现了setjmp longjmp能够在资源竞争条件下对alarm和pause对进行保护。
上述代码在main()中调用sleep2()函数。
进入到sleep2()函数之后,先注册一个SIGALRM的信号处理函数 → 再在setjmp保护下,alarm(second)设定倒计时 → 随后马上执行kill命令,向进程自身发送一个SIGINT信号,触发sig_int函数 → sig_int函数中执行的任务远超过alarm(second)中second的限制,为的就是模拟资源竞争时alarm已经倒计时完毕的时候,pause()还没开始。
由于sleep2()中保护机制的存在,如果由于资源竞争导致“alarm已经执行完毕,但是pause还没开始”,longjmp就直接跳到setjmp的地方了,并且返回的值为1;这样就跳过了pause()的语句,自然也就不会无限期的等待了。
b. 上述代码也体现了setjmp longjmp这种机制的隐患。
加入不是人为产生资源竞争,而是进程真的在执行某些任务;这个时候由于alarm到时,强制longjmp结束,很有可能造成其他任务还没处理完成,就直接longjmp结束了。
总结一下,要慎用setjmp和longjmp这样的长跳转机制。
10.11 10.12 10.13 sigset_t & sigprocmask & sigpending
1. sigset_t
有时候我们需要设定,一个进程要屏蔽哪些信号、要接受哪些信号、记录进程原来对信号的设定状况等。这个时候,就需要一种信号集合的数据结构,以及围绕其的一些周边函数来完成。其中数据结构就是sigset_t。
2. int sigprocmask(int how, const sigset_t *restrict set, sigset_t *restrict oset)
设定信号mask。
how : 修改信号mask的方式,SIG_BLOCK、SIG_UNBLOCK、SIG_SETMASK
ret : 信号mask被设定成设么样
oret : 保留原来的信号mask
返回值表示函数执行成功或失败。
3. int sigpending(sigset_t *set)
获得当前进程有哪些信号被pending了。
看一个例子:
#include "apue.h" static void sig_quit(int signo) { printf("caught SIGQUIT\n"); signal(SIGQUIT, SIG_DFL); } int main() { sigset_t newmask, oldmask, pendmask; signal(SIGQUIT, sig_quit); /*捕捉退出信号*/ sigemptyset(&newmask); /*初始化新的信号mask*/ sigaddset(&newmask, SIGQUIT); /*在newmask中添加退出信号*/ sigprocmask(SIG_BLOCK, &newmask, &oldmask); /*阻塞SIGQUIT信号*/ sleep(5); sigpending(&pendmask); /*获得有当前进程被阻塞的信号*/ if (sigismember(&pendmask, SIGQUIT)) { printf("\nSIGQUIT pending\n"); } sigprocmask(SIG_SETMASK, &oldmask, NULL); /*释放被阻塞的信号*/ printf("SIGQUIT unblocked\n"); sleep(5); exit(0); }
代码执行结果如下:
分析如下:
(1)上述代码首先用sigprocmask阻塞了SIGQUIT信号;经过第一个sleep(5)之后,马上执行sigpending,获得了当前被阻塞的信号,并且得到了验证SIGQUIT确实在被阻塞的信号集合pendmask中。
(2)紧接着再用sigprocmask函数释重新恢复了信号mask的值,即释放被阻塞的信号;随后,之前被阻塞的SIGQUIT信号马上就进来了,并且触发了sig_quit信号处理函数;注意,在信号处理函数中恢复了对SIGQUIT的默认处理方式。
(3)即使第一个sleep(5)的时候输入了多个ctrl+\输入信号,最终被处理的SIGQUIT信号也只有一个(最起码在我使用的Linux系统上是这样的)。
在上述代码基础上再扩展一下,如果多个不同的信号被pending住,当unblock的之后,会有什么效果呢?将书上的代码修改如下:
#include "apue.h" static void sig_quit(int signo) { printf("caught SIGQUIT\n"); signal(SIGQUIT, SIG_DFL); } static void sig_int(int signo) { printf("caught SIGINT\n"); signal(SIGINT, SIG_DFL); } int main() { sigset_t newmask, oldmask, pendmask; signal(SIGQUIT, sig_quit); /*捕捉退出信号*/ signal(SIGINT, sig_int); /*捕捉中断信号*/ sigemptyset(&newmask); /*初始化新的信号mask*/ sigaddset(&newmask, SIGQUIT); /*在newmask中添加退出信号*/ sigaddset(&newmask, SIGINT); /*阻塞interrupt信号*/ sigprocmask(SIG_BLOCK, &newmask, &oldmask); /*阻塞SIGQUIT信号*/ sleep(5); sigpending(&pendmask); /*获得有当前进程被阻塞的信号*/ if (sigismember(&pendmask, SIGQUIT)) { printf("\nSIGQUIT pending\n"); } if (sigismember(&pendmask, SIGINT)) { printf("\nSIGINT pending\n"); } sigprocmask(SIG_SETMASK, &oldmask, NULL); /*释放被阻塞的信号*/ printf("SIGQUIT unblocked\n"); printf("SIGINT unblocked\n"); sleep(5); exit(0); }
不仅阻塞了SIGQUIT信号,而且还阻塞SIGINT信号。再执行代码如下:
分析如下:
(1)可以看到,对于同类的信号被阻塞信号,只获取一个;对于不同类的阻塞信号,可以把不同类等待的信号分别处理了。
(2)对比两次运行程序,虽然输入信号的顺序是不同的,但是执行信号处理函数的顺序却没有改变。
针对以上两点内容,google了一下相关资料:这个blog的解释非常好http://galex.cn/【apue】信号/
上述的信号是经典信号,不支持排队,而且信号的响应顺序和信号到来的顺序根本没有关系。恩,暂时这样理解。
10.14 10.15 sigaction Function & sigsetjmp siglongjmp Function
1. int sigaction(int signo, const struct sigaction *restrict act, struct sigaction *restrict oact)
本质上用于信号处理函数的注册,signal(2)的加强改进版。执行成功返回0,出错返回-1。
signo : 要处理的信号
act : 对信号处理函数的新设定
oact : 之前注册的signo信号处理函数的信息
其中sigaction是结构体变量,里面不仅存放了信号处理函数,而且还有需要屏蔽掉的信号集合,以及其他信息。
struct sigaction{
void (*sa_handler) (int); /*信号处理函数*/
sigset_t sa_mask; /*需要屏蔽的信号*/
...
}
这里的屏蔽信号指的是执行信号处理函数前希望屏蔽掉的信号;当信号处理函数执行完并return的时候,信号mask就会恢复到之前的状态。
回想之前在signal handler中重新调用signal的例子,应用sigaction函数就可以做到“Hence, we are guaranteed that whenever we are processing a given signal, another occurrence of that same signal is blocked until we're finished processing the first occurrence”
另外,用sigaction函数注册的信号处理函数,只要注册一次就一直生效;除非显式修改该信号的处理函数。
2. sigsetjmp & siglongjmp
int sigsetjmp(sigjmp_buf env, int savemask)
返回0代表是设置jmp点;返回非零值代表从别处跳回来,具体是什么值在跳的时候决定。
env : 目前还不详
savemask : 执行跳转之前的信号mask值
void siglongjmp(sigjmp_buf env, int val)
跳到sigsetjmp的地方,其中val要求是非零值,即sigsetjmp的返回值。
之前已经有setjmp和longjmp这种终极长跳转函数对了,为什么还要有sigsetjmp和siglongjmp函数对呢?
考虑下面这种情况:
a. 假设进入到了信号处理函数中(此时,假设同类信号已经被blocked了),该类信号已经在mask中设置为blocked了;
b. 如果signal handler被顺利执行完,这时信号mask就恢复到执行signal handler之前的状态了
c. 但是,如果signal handler执行到中间,执行到了longjmp语句了,很可能就把信号mask恢复这个环节就个跳过去了
d. 信号mask没有恢复的问题就是,本来同类信号可以再继续被处理,但是由于没有恢复信号mask,就不能被处理了
上面的情况,也是sigsetjmp和siglongjmp的设计初衷。
下面看一个例子(基于书上Figure 10.20的示例改造的),实际体会一下sigsetjmp和siglongjmp的函数对的作用:
#include "apue.h" #include <setjmp.h> #include <time.h> #include <errno.h> static sigjmp_buf jmpbuf; static volatile sig_atomic_t canjmp; /*获得当前进程是否mask了某种信号*/ void pr_mask(const char *str) { sigset_t sigset; int errno_save; errno_save = errno; sigemptyset(&sigset); if ( sigprocmask(0,NULL,&sigset)<0 ) //获得当前的signal set情况 { err_ret("sigprocmask error"); errno = errno_save; return; } printf("%s",str); //打印调用信息title if ( sigismember(&sigset, SIGINT) ) printf(" SIGINT"); if ( sigismember(&sigset, SIGQUIT) ) printf(" SIGQUIT"); if ( sigismember(&sigset, SIGUSR1) ) printf(" SIGUSR1"); if ( sigismember(&sigset, SIGALRM) ) printf(" SIGALRM"); printf("\n"); errno = errno_save; } /*SIGUSR1的信号处理函数*/ void sig_usr1(int signo) { time_t starttime; if (canjmp==0) return; pr_mask("starting sig_usr1: "); alarm(3); starttime = time(NULL); for (; ;) /*busy等待5秒*/ if (time(NULL)>starttime+5) break; pr_mask("finishing sig_usr1: "); canjmp = 0; siglongjmp(jmpbuf,1); /*longjmp(jmpbuf,1);*/ } /*SIGALRM信号处理函数*/ void sig_alarm(int signo) { pr_mask("in sig_alrm: "); } int main() { struct sigaction siga1,siga2; siga1.sa_handler = sig_usr1; sigemptyset(&siga1.sa_mask); sigaddset(&siga1.sa_mask, SIGUSR1); siga2.sa_handler = sig_alarm; sigemptyset(&siga2.sa_mask); sigaddset(&siga2.sa_mask, SIGALRM); sigaction(SIGUSR1, &siga1, NULL); sigaction(SIGALRM, &siga2, NULL); pr_mask("staring main: "); if (/*setjmp(jmpbuf)*/sigsetjmp(jmpbuf,1)) { pr_mask("ending main: "); exit(0); } canjmp = 1; for(; ;) pause(); }
程序运行结果如下:
(1)用sigsetjmp和siglongjmp函数对的运行结果:
(2)用setjmp和longjmp函数对的运行结果:
对比以上两个运行结果可以看到,sigsetjmp和siglongjmp函数对确实很好地保护了信号mask现场,不会因为jmp的动作就导致某些信号mask位没有被恢复过来。(另,在我运行的系统上,如果直接用signal还不太行,必须用sigaction函数才可以获得上述的结果;原因就是系统的signal没有实现同类信号屏蔽)
10.18 system Function
这个部分主要说system这个函数与signal相关的内容:POSIX.1标准要求system必须忽略SIGINT和SIGQUIT信号,屏蔽SIGCHLD信号。
下面用正反两个例子来说明为什么有上述的要求。
例子一
#include <unistd.h> #include <signal.h> #include <stdio.h> #include <errno.h> int system(const char *cmdstring) /* version without signal handling */ { pid_t pid; int status; if (cmdstring == NULL) return(1); /* always a command processor with UNIX */ if ((pid = fork()) < 0) { status = -1; /* probably out of processes */ } else if (pid == 0) { /* child */ execl("/bin/sh", "sh", "-c", cmdstring, (char *)0); _exit(127); /* execl error */ } else { /* parent */ while (waitpid(pid, &status, 0) < 0) { if (errno != EINTR) { status = -1; /* error other than EINTR from waitpid() */ break; } } } return(status); } static void sig_int(int signo) { printf("caught SIGINT\n"); } static void sig_chld(int signo) { printf("caught SIGCHILD\n"); } static void sig_usr1(int signo) { printf("caught SIGUSR1\n"); } int main() { signal(SIGINT, sig_int); signal(SIGCHLD, sig_chld); signal(SIGUSR1, sig_usr1); system("/bin/ed"); }
程序运行结果如下:
分析如下:
-------------插播一段ed的背景知识-------------
首先需要补充一下/bin/ed这个程序有关信号的特点:
(1)ed捕获SIGINT和SIGQUIT信号
(2)对于SIGINT信号:prints a question mask
(3)对于SIGQUIT信号的处理方式:ignore
为了验证ed的特性,我做了如下的试验:
两个窗口是tmux开的,左侧是调用/bin/ed的窗口;右侧的是发送signal用的(另,不知道tmux的,可以参考我的这篇blog)
可以看到开启ed程序后,向其发送SIGINT信号,真的再终端反馈输出一个?;向其发送SIGQUIT信号,并么有什么反应。
------------------------插播结束-------------------------
现在开始切入正题。
先分析运行结果
(参考http://blog.csdn.net/windeal3203/article/details/39049291和http://blog.csdn.net/ctthuangcheng/article/details/9258715):
(1)终端输入ctrl+c,前台进程都会受到这个信号;这里的前台进程包括ed shell a.out三个进程(其中shell自动忽略SIGINT信号,不讨论)
(2)ed在收到SIGINT后,自然会输出一个?;而a.out中注册了SIGINT的处理函数,因此也会触发信号处理函数
(3)输入q之后,ed退出,发送一个SIGCHLD信号;由于a.out是ed的父进程(看红框中的pid和ppid),所以自然收到SIGCHLD信号,并触发信号处理函数
请注意,上述的system函数是去除了signal设定的阉割版,并没有符合POSIX.1的标准。
我们需要一直记着:这个/bin/ed是由system函数调用的,这样带来的问题有两个:
(1)由于终端正在运行的是/bin/ed程序,输入的ctrl+c的想法是给ed的,并不是给a.out的,a.out错误接收到了发给ed的SIGINT了;这个时候如果a.out还有其他的任务要执行,并且没有处理SIGINT的机制,就被强制关闭了。
(2)当ed执行完毕退出的时候,相当于child process结束,因此会给parent process的a.out发送一个SIGCHLD信号;其实这个ed一旦由system函数执行上,就跟a.out没有太大关系了,a.out错误接收了发给ed的SIGCHLD了,认为是自己的进程执行完毕了。
我个人理解,system function虽然说某种程度上方便了启动某些程序;但通过上述的分析,system Function也是一个挺别扭的事情。要想知道别扭的原因,需要参考一下system的实现(不考虑signal版):
int system(const char *cmdstring) /* version without signal handling */ { pid_t pid; int status; if (cmdstring == NULL) return(1); /* always a command processor with UNIX */ if ((pid = fork()) < 0) { status = -1; /* probably out of processes */ } else if (pid == 0) { /* child */ execl("/bin/sh", "sh", "-c", cmdstring, (char *)0); _exit(127); /* execl error */ } else { /* parent */ while (waitpid(pid, &status, 0) < 0) { if (errno != EINTR) { status = -1; /* error other than EINTR from waitpid() */ break; } } } return(status); }
(1)显然system的实现利用fork和exec两个重要的函数:fork就是分叉生成一个child process;exec的作用是让child process用shell运行程序;可以说system利用了fork和exec实现了极大的代码便利
(2)但是fork和exec必然会对parent process有影响,比如上面提到的信号问题。
上述两个方面(1)简化了工作,(2)复杂了工作,所以说system Function是个别扭的函数。
例子二
给出另一个system实现(在原书的代码上做了一些修改,主要是方便显示),代码如下:
#include <sys/wait.h> #include <errno.h> #include <signal.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> static void sig_int(int signo) { printf("caught SIGINT\n"); } static void sig_chld(int signo) { printf("caught SIGCHILD\n"); } int i_system(const char *cmdstring) /* with appropriate signal handling */ { pid_t pid; int status; struct sigaction ignore, saveintr, savequit; sigset_t chldmask, savemask; if (cmdstring == NULL) return(1); /* always a command processor with UNIX */ ignore.sa_handler = SIG_IGN; /* ignore SIGINT and SIGQUIT */ sigemptyset(&ignore.sa_mask); ignore.sa_flags = 0; if (sigaction(SIGINT, &ignore, &saveintr) < 0) return(-1); if (sigaction(SIGQUIT, &ignore, &savequit) < 0) return(-1); sigemptyset(&chldmask); // now block SIGCHLD sigaddset(&chldmask, SIGCHLD); if (sigprocmask(SIG_BLOCK, &chldmask, &savemask) < 0) return(-1); if ((pid = fork()) < 0) { status = -1; /* probably out of processes */ } else if (pid == 0) { /* child */ /* restore previous signal actions & reset signal mask */ sigaction(SIGINT, &saveintr, NULL); sigaction(SIGQUIT, &savequit, NULL); sigprocmask(SIG_SETMASK, &savemask, NULL); execl("/bin/sh", "sh", "-c", cmdstring, (char *)0); _exit(127); /* exec error */ } else { /* parent */ while (waitpid(pid, &status, 0) < 0) if (errno != EINTR) { printf("error\n"); status = -1; /* error other than EINTR from waitpid() */ break; } } printf("ed ends\n"); /* restore previous signal actions & reset signal mask */ if (sigaction(SIGINT, &saveintr, NULL) < 0) return(-1); if (sigaction(SIGQUIT, &savequit, NULL) < 0) return(-1); if (sigprocmask(SIG_SETMASK, &savemask, NULL) < 0) return(-1); printf("return from system\n"); return(status); } int main() { signal(SIGINT, sig_int); signal(SIGCHLD, sig_chld); i_system("/bin/ed"); printf("after ed\n"); }
代码执行结果:
结果分析:
(1)当终端输入q之后,ed进程结束,并向父进程发送SIGCHLD信号
(2)但是由于i_system执行过程中屏蔽了SIGCHLD信号,因此ed结束后先被主进程waitpid收尸,这个时候父进程a.out是不会收到SIGCHLD信号的
(3)最后,当所有与ed相关的内容都处理完了之后,最后一个sigprocmask放开SIGCHLD信号的阻塞
(4)之前由于ed进程结束带来的SIGCHLD信号马上被处理了,触发sig_chld信号处理函数
可以看到,由于system忽略了SIGINT和SIGQUIT信号,在system的执行过程中,不会由于终端发出ctrl+c就会影响父进程a.out的运行;并且由于屏蔽了SIGCHLD信号,不会使得父进程误收到SIGCHLD信号;只有当所system中执行的所有内容都结束后,才会释放对SIGCHLD的阻塞。
system这个函数考虑的问题太多,实际用到的时候要把与signal相关的东西考虑清楚。