是这么回事，我公司的一个项目某个模块里，发现了一个bug，就是当多线程开启的时候，之前设置在signal()里的信号就会自动失效，例如表现为Ctrl-C无效。
我初步估计是某个函数或代码段自动屏蔽了信号，但是上网查了很多资料，发现会自动屏蔽信号的函数在我们这个模块里都没用到。或者有我不了解。
最后我采用折中的办法，在程序某个地方重新调用signal()，似乎是跳过了屏蔽信号的代码段，信号又有效啦。
但今天发现可能会有隐患，因为我似乎是把signal()放在一个循环里，或者说程序运行时可能会反复调用signal()，而且我们那个系统一旦启动是不关机的。。。
我不知道反复调用signal()会不会有副作用，比如反复调用malloc()系统肯定死机。signal()是不是每次调用只占用的栈空间，这样函数返回时占用的资源会自动撤销。
如果会调用堆空间就完啦。
希望懂得signal()原理的帮个忙啊，谢谢~~~~~~~~~~~~~~

比如反复调用malloc()系统肯定死机,那是因为你申请了资源没有释放，当然会宕机了，呵呵～～～

就看你这signal()是否合理，系统中很多函数为了保证不可重入性，会采取不允许抢占的方式。如果你的sig是实时性要求很强的话，你的做法是可以接受的，我认为应该没有宕机的危险。

如果你是进程间的通信有很多方式可以进行，如管道、共享内存等，如果是内核给用户态发送消息的话，也可以使用netlink等手段，其实个人认为使用信号（除非非使用不可的话），不是一个最好的方法

首先 无限循环调用 signal肯定不是个合理的编程方式

其次 应该不会让程序 down掉，它只是安装一个 sig_handler而已了，替换掉原来的handler.

最后，自己也可以写小程序 运行看看， while(signal() != NULL); 看看 内存有没有一直下降。

发现了一个bug，就是当多线程开启的时候，之前设置在signal()里的信号就会自动失效，例如表现为Ctrl-C无效。

===================================

Linux implements threads as separate processes, sharing resources using 
clone(2). Because of this, the behavior of threads on Linux differs from that 
on other implementations when it comes to signals. In the POSIX.1 thread model,
 asynchronous signals are sent to a process, and then an individual thread 
within the process is selected to receive the signal, based on which threads 
are not currently blocking the signal. On Linux, an asynchronous signal is sent
 to a particular thread, and since each thread executes as a separate process, 
the system is unable to select a thread that isn't currently blocking the 
signal. The result is that the thread may not notice the signal.

Excerpt from APUE V2 ch12.8

你可以查一下为什么会"某个函数或代码段自动屏蔽了信号"?另外....建议你用sigaction这个FUN...