自定义linux信号

有时候我们需要在程序中利用信号来控制程序行为，linux为我们提供了2个已经定义的信号SIGUSR1和SIGUSR2，一般的程序利用这2个信号已经能满足需要，不过我最近需要一些其他信号来避免覆盖原来的信号处理函数。

#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之后就没有问题了。不过这个方法不太可靠，程序不应该直接用常量标识信号. 

打赏