【IPC 通信】信号处理接口 Signal API(1)

         收发信号思想是 Linux 程序设计特性之一,一个信号可以认为是一种软中断,通过用来向进程通知异步事件。

        本文讲述的 信号处理内容源自 Linux man。本文主要对各 API 进行详细介绍,从而更好的理解信号编程。


signal

遵循 C11,POSIX.1 - 2008

1.库

标准 c 库,libc, -lc

2.头文件

3.接口定义

       #include 

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

4.接口描述

       注意:signal() 的行为会根据不同的 UNIX 版本而变化,同样它也会根据 Linux 版本的不同而不同。考虑到程序的可移植性,尽量避免 signal() 的使用,而是使用 sigacton(2) 代替,可以参考下面移植性部分。

        signal() 设置 signum 信号的处理函数为 handler,处理函数可以是SIG_IGN、SIG_DFL,也可以是程序设计人员定义的函数地址。

        如果 signum 被分发给到一个进程,那么会发生以下行为:

  • 如果处理函数设置成了 SIG_IGN,那么信号会被忽略。
  • 如果处理函数设置成了 SIG_DFL,那么信号的默认关联行为会发生(可以参考 signal(7))。
  • 如果处理函数设置成了一个函数,那么首先会将默认处理函数复位为 SIG_DFL,或者信号被阻塞(参考下面可移植性部分),然后会调用 handler 函数并传递 signum 参数。如果处理函数调用导致了该信号处理阻塞,那么在处理函数返回后,该信号会重新被 unblock。

        SIGKILL 和 SIGSTOP 两个信号不能被捕捉或者忽略。

5.返回值

        signal() 返回信号之前 的处理函数值。发生错误时,signal() 会返回 SIG_ERR,并设置 errno 来提示具体错误。

        错误值定义如下:

EINVAL signum 参数不合法

6.版本

       sighandler_t 是一个 GNU 扩展,它会在 _GNU_SOURCE 定义时暴漏出来。如果定义了_BSD_SOURCE(glibc 2.19 或低版本) 或者 _DEFAULT_SOURCE(glibc 2.19 或高版本),glibc 也定义了 sig_t。不使用这些定义的情况下,signal() 的声明就会有些晦涩:

           void ( *signal(int signum, void (*handler)(int)) ) (int);

可移植性 

        signal() 只有在将 handler 设置为 SIG_DFL/SIG_IGN 时,才具有移植性。使用 signal() 建立信号处理函数的语义随着系统的不同而不同,POSIX.1 明确允许这些不同的行为。所以不要使用它于此目的。

        POSIX.1 通过 sigaction(2) 接口解决了这种移植上的混乱,sigaction(2)  提供了信号处理调用的明确语义定义。所以,使用 sigaction(2) 来代替 signal()。

7.历史

        C89,POSIX.1-2001

        在原来的 UNIX 系统中,当使用 signal() 建立的信号处理函数被调用时,信号的处理会被设置成 SIG_DFT,并且系统不会阻塞该信号通往其他进程的发布。这相当于调用了 sigaction(2),附带以下标记:

           sa.sa_flags = SA_RESETHAND | SA_NODEFER;

         System V 已提供了 signal() 的语义,不过这个定义有点差劲,因为在处理函数重新建立连接前,可能会连续收到两个信号。更严重的,同一个信号的频繁分发会导致处理函数的递归调用。

        BSD 对此进行了改善,但不幸的是这种改善却改变了现存 signal() 接口的语义。在 BSD 系统上,当一个处理函数调用时,信号处置并没有被重新设置,后面发生的该信号的实例因该处理函数正在执行无法进行分发。更严重的,一些阻塞系统调用会在信号处理函数打断后自动重启。BSD 语义相当于使用下面标记调用 sigaction(2):

           sa.sa_flags = SA_RESTART;

         Linux 上的情景如下:

  • 内核的 signal() 系统调用提供了 System V 语义
  • 默认情况下,glibc 2 及更高版本的 signal() 封装并没有调用内核系统调用,而是调用了 sigaction(2),提供 BSD 语义的标记。只要提供合适的宏定义,就可以提供以上默认行为:glibc 2.19 或低版本的 _BSD_SOURCE 或者 2.19 或更高版本的 _DEFAULT_SOURCE。(默认情况下,这些宏是定义了的,参考 feature_test_macros(7) )。如果这些测试宏没有开启,那么 signal) 提供的是 System V 语义。 

 8.注意

        signal() 在进程的多线程场景下的副作用是未定义的。

        根据 POSIX 定义,进程忽略非 kill(2)/raise(3) 产生的 SIGFPE/SIGILL/SIGSEGV 信号后的行为是未定义的。整数除以 0 是未定义的结果,在一些架构上它会产生 SIGFPE 信号(同样使用 -1 除最大负整数也可能产生 SIGFPE。)忽略这些信号可能会导致无限循环。

        参考 sigaction(2) 获取更多关于将 SIGCHLD 信号的处置设置为 SIGIGN 的信息。

        参考 signal-safety(7) 来查看一些可以在信号处理函数内部调用的异步信号安全的函数。

9.代码

        下面是一个捕捉 CTRL + C 信号的程序。

#include 
#include 
#include 
#include 

void sighandler(int);

int main()
{
   signal(SIGINT, sighandler);

   while(1) 
   {
      printf("开始休眠一秒钟...\n");
      sleep(1);
   }

   return(0);
}

void sighandler(int signum)
{
   printf("捕获信号 %d,跳出...\n", signum);
   exit(1);
}

你可能感兴趣的:(信号处理,signal,linux,SIGKILL,SIGINT)