linux自定义信号处理
2013-11-05 20:08
1416 查看
有时候我们需要在程序中利用信号来控制程序行为,linux为我们提供了2个已经定义的信号SIGUSR1和SIGUSR2,一般的程序利用这2个信号已经能满足需要,不过我最近需要一些其他信号来避免覆盖原来的信号处理函数。
上网查了一下,看到了下面的程序片段:
然后到系统里查了一下,MYSIG_MSG其实将其他的信号给覆盖了:
$kill -l 显示 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM
虽然SIGPIPE和SIGALRM在这个程序中没有用到,但是这并不是我想要的效果。
我发现在后面有 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 ,man 7 signal页面同样也说明可以用 SIGRTMIN作为自定义信号。然后程序里就多了下面的代码:
结果当然是出错了咯,但是并不是这个定义方式的问题。在我程序中有下面的代码:
编译时才发现原来SIGRTMIN并不是一个常量,看了头文件里才知道:
原来是函数调用,运行时确定的。
要用这个SIGRTMIN宏是不行,只能自己定义了:
在找到系统定义的SIGRTMIN值之前,根据man 7 signal里面的说明:
Linux supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX).
我把自定义的信号值定义成了32,但是一直注册不了这个信号,后来赫然发现在 man 7 signal下面有一行说明,
However, the glibc POSIX threads implementation internally uses two (for NPTL) or three (for LinuxThreads) real-time signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably (to 34 or 35)
这个说明在ubuntu12.04里面看见的,估计centos也有类似的情况。同时头文件下面也有:
改成34之后就没有问题了。虽然在man里面说明了程序不应该直接用常量标识信号,不过为了达到我的目的也顾不了了。
记录一点东西来当作回忆。
上网查了一下,看到了下面的程序片段:
#define MYSIG_MSG (SIGUSR2 + 1) // 定义信号然后注册处理函数
然后到系统里查了一下,MYSIG_MSG其实将其他的信号给覆盖了:
$kill -l 显示 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM
虽然SIGPIPE和SIGALRM在这个程序中没有用到,但是这并不是我想要的效果。
我发现在后面有 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 ,man 7 signal页面同样也说明可以用 SIGRTMIN作为自定义信号。然后程序里就多了下面的代码:
#define MYSIG_MSG (SIGRTMIN+ 1)
结果当然是出错了咯,但是并不是这个定义方式的问题。在我程序中有下面的代码:
switch(signo){ case MYSIG_MSG: break; }
编译时才发现原来SIGRTMIN并不是一个常量,看了头文件里才知道:
// centos5.9 /usr/include/bits/signum.h #define SIGRTMIN (__libc_current_sigrtmin ())
原来是函数调用,运行时确定的。
要用这个SIGRTMIN宏是不行,只能自己定义了:
#define MYSIGRTMIN 34 #define MYSIG_MSG (MYSIGRTMIN + 1)
在找到系统定义的SIGRTMIN值之前,根据man 7 signal里面的说明:
Linux supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX).
我把自定义的信号值定义成了32,但是一直注册不了这个信号,后来赫然发现在 man 7 signal下面有一行说明,
However, the glibc POSIX threads implementation internally uses two (for NPTL) or three (for LinuxThreads) real-time signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably (to 34 or 35)
这个说明在ubuntu12.04里面看见的,估计centos也有类似的情况。同时头文件下面也有:
/* These are the hard limits of the kernel. These values should not be used directly at user level. */ #define __SIGRTMIN 32 #define __SIGRTMAX (_NSIG - 1)
改成34之后就没有问题了。虽然在man里面说明了程序不应该直接用常量标识信号,不过为了达到我的目的也顾不了了。
记录一点东西来当作回忆。
相关文章推荐
- linux 信号&信号处理 .
- linux信号signal处理函数 ,多线程信号处理
- Linux 信号signal处理机制
- linux 信号处理函数详解
- Linux 信号处理,是否同一个线程组的线程收到SIGSEGV其它线程都会被挂起
- Linux向进程发送信号及执行信号处理函数的时机
- Linux信号、信号处理和信号处理函数
- Linux 多线程应用中如何编写安全的信号处理函数
- Linux C 信号处理
- Linux下多线程编程与信号处理易疏忽的一个例子
- 【linux信号】信号处理函数执行后返回到信号发生处
- linux下的信号处理函数总结
- linux信号处理机制的原理
- linux编程---信号中断处理
- Linux 多线程应用中如何编写安全的信号处理函数
- linux 信号处理机制——signal
- linux-0.11内核 信号处理小结
- linux 信号处理
- Linux--信号处理:在某个信号发生时屏蔽其他的信号
- 浅谈Linux中的信号处理机制(二)