2016-02-15

信号

信号概念

每个信号都有一个名字，这些名字都以三个字符SIG开头。eg SIGABRT SIGALRM
在头文件<signal.h>中，这些信号都被定义为正整数。很多条件会产生一个信号

• 当用户按某些终端键时，产生信号。在终端上按DELETE键通常产生中断信号（SIGINT）这是停止一个已经失去控制程序的方法。
• 硬件异常产生信号：除数为0、无效的存储访问等等。这些条件通常由硬件检测到，并将其通知内核。然后内核为该条件发生时正在运行的进程产生适当的信号。
• 进程调用kill(2)函数可将信号发送给另一个进程或进程组。接收信号进程和发送信号进程的所有者必须相同，或发送信号进程的所有者必须是超级用户。
• 当检测到某种软件条件已经发生时，并将其通知有关进程时也产生信号。这里并不指硬件产生条件，而是软件条件，如SIGURG（在网络连接上传来非规定波特率的数据）、SIGPIPE（在管道的读进程已终止后一个进程写此管道），以及SIGALRM(进程所这只的闹钟时间已经超时)

信号是一步时间的经典实例。产生信号的事件对进程而言是随机出现的。进程不能只是测试一个变量来判别是否发生了一个信号，而是必须告诉内核“在此信号发生时，请执行下列操作”
可以要求系统在某个信号出现时按照下列三种方式中的一种进行操作

• 忽略此信号。大多数信号都可使用这种方式进行处理。但有两种信号绝不能被忽略。SIGKILL和SIGSTOP这两种信号不能被忽略的原因是他们向超级用户提供一种使进程停止或者终止的可靠方法。另外如果忽略某些由硬件异常产生的信号，则继承的行为是未定义的。

• 捕捉信号。为了做到这一点要通知内核在某种信号发生时，调用一个用户函数。在用户函数中，可执行用户希望对这种时间进程的处理。

• 执行系统默认动作。对大多数信号的系统默认动作是终止该进程。
  在系统默认动作列 终止w/core表示在进程当前工作目录的core文件中复制了该进程的存储图像。大多数unix调试程序都是用core文件检查进程终止时的状态。在下列条件下不产生core文件 进程是设置用户id而且当前用户并非程序文件所有者，进程是设置组id而当前用户并非该程序文件的组所有者，或者用户没有写当前目录的权限，或者文件太大。core文件的许可权通常是用户读写组读和其他读

• SIGABRT 调用abort函数时产生此信号。进程异常终止。

• SIGALRM 超过用alarm函数设置的时间时产生此信号。若由settimer函数设置的时间间隔已经过时，那么也产生此信号。

• SIGBUS 只是一个实现定义的硬件故障。

• SIGCHLD 在一个进程终止或者停止时，SIGCHLD信号被送给其父进程。按系统默认，将忽略此信号。如果父进程希望了解其子进程的这种状态，则应捕捉此信号。信号捕捉函数中通常要用wait函数以取得子进程id和终止状态

• SIGCONT 此作业控制信号送给需要继续运行的处于停止状态的进程。如果接收到此信号的进程处于停止状态，则系统默认动作是使该进程继续运行，否则默认动作是忽略。

• SIGEMT 指示一个实现定义的硬件故障。

• SIGFPE 此信号表示一个算术运算异常。

• SIGHUP 如果终端界面检测到一个连接断开，则此信号传送给该终端相关的控制进程。

• SIGILL 此信号指示进程已执行一条非法硬件指令。

• SIGINFO 当用户按状态键（ctrl+T）终端驱动程序产生此信号并送至前台进程组中的每一个进程。此信号通常造成在终端上显示前台进程组中各进程的状态信息。

• SIGINT 当用户按中断键终端驱动程序产生此信号并送至前台进程组的每一个进程。

• SIGIO 此信号指示一个异步io事件

• SIGIOT 表示一个实现定义的硬件故障

• SIGKILL 杀死进程

• SIGPIPE 如果在读进程已终止时写管道，则产生此信号。

• SIGPOLL 当在一个可轮询的设备上发生一特定事件时产生此信号。

• SIGPROF 当setitimer函数设置的梗概统计时间间隔已超过时产生此信号

• SIGPWR 它主要用于具有不间断电源的系统上。如果电源失效，则ups起作用，而且通常软件会接到通知。

• SIGQUIT 当用户在终端上按退出键时产生此信号，并送至前台进程组所有进程。此信号不仅终止前台进程组，同时产生一个core文件

• SIGSEGV 进程进行了一次无效的存储访问

• SIGSTOP 这是一个作业控制信号，它停止一个进程，它类似交互停止信号SIGTSTP但其不能被捕捉或忽略。

• SIGSYS 指示一个无效的系统调用。

• SIGTERM 这是kill命令发送的系统默认终止信号

• SIGTRAP 指示一个实现定义的硬件故障

• SIGTSTP 交互停止信号，当用户在终端上按挂起键（一般Ctrl+Z）时终端驱动产生此信号。

• SIGTTIN 当一个后台进程组试图读其控制终端时，终端驱动程序产生此信号。

• SIGTTOU 当一个后台进程组进程试图写其控制终端信号时产生此信号

• SIGURG 此信号通知进程已经发生一个紧急情况。在网络连接上，接到非规定波特率的数据时此信号可选择的产生。

• SIGUSR1 这是一个用户定义的信号，可用于应用程序

• SIGUSR2 用户自定义信号

• SIGVTALARM 当一个由setitimer函数设置的虚拟间隔时间已经超过时产生此信号。

• SIGWINCH 内核保持与每个终端或者伪终端相关联的窗口大小。一个进程可以用ioctl函数得到或者设置窗口大小。如果一个进程用ioctl设置了窗口大小则发送此信号

• SIGXCPU 如果进程超过了其软cpu时间限制则产生此信号

• SIGXFSZ 如果进程超过了其软文件长度限制，则产生此信号。

signal函数

#include<signal.h>
void (*signal (int signo, void(*func)(int)))(int);

signo参数时信号名，func的值是：常数SIG_IGN表示忽略此信号，SIG_DFL表示默认动作，当指定函数地址时我们称此为捕捉此信号。我们称此函数是信号处理程序或者信号捕捉函数

程序启动

当执行一个程序时，所有信号的状态都是系统默认或者忽略。通常都是系统默认，除非调用exec的进程忽略该信号。比较特殊的是exec函数将原先设置为要捕捉的信号都设置为默认动作，其他信号的状态则不变（一个进程原先要捕捉的信号，当其执行一个新的程序后紫檀不能再捕捉了，因为信号捕捉函数的地址很可能在所执行的新程序文件中已无意义）

进程创建

当一个进程调用fork时其子进程继承父进程的信号处理方式，因为子进程在开始时复制了父进程存储图像，所以信号捕捉函数的额地址在子进程中是有意义的。

不可靠信号

早期的unix版本中信号发生后进程不一定会收到。那时进程对信号的控制能力也很低，它能捕捉信号或者忽略它，但有些很需要的功能并不具备。例如有时用户希望通知内核阻塞一信号不忽略该信号，在其发生时记住它，然后再进程做好了准备时再通知他，这种阻塞信号的能力当时并不具备。
早期版本中的一个问题是在进程每次处理信号时随即将信号动作复置为默认值。这些早期版本的另一个问题是在进程不希望某种信号发生时，它不能关闭该信号。进程能做的就是忽略该信号。

中断的系统调用

早期的unix系统的一个特性是：如果在进程执行一个低速系统调用而阻塞期间捕捉到一个信号，则该系统调用就被中断不再继续执行。该系统调用返回出错，其errno设置为EINTR。这样处理的理由是因为一个信号发生了，进程捕获了它，这意味着已经发生了某种事情，所以是个好机会应当缓行阻塞的系统调用。
为了支持这种特性，将系统调用分成两类：低速系统调用和其他系统调用。低速系统调用是可能会使进程永远阻塞的一类系统调用，其包括：

• 在读某些类型的文件时，如果数据并不存在则可能会使调用者永远阻塞。
• 在写这些类型的文件时，如果不能立即接受这些数据，则也可能会使调用者永远阻塞
• 打开文件，在某种条件发生之前也可能会使调用者阻塞（如：打开终端设备，它要等待直到所连接的调制解调器回应）
• pause和wait
• 某种ioctl操作
• 某些进程间通信函数

在这些低速系统调用中一个值得注意的例外是与磁盘io有关的系统调用。虽然读写磁盘文件有可能暂时阻塞调用者，但除非发生硬件错误，io操作总会很快返回。
可以用中断系统调用这种方法来处理的一种情况是一个进程启动了读终端的操作，而使用该终端设备的用户却离开终端很长时间。这种情况下进程可能处于阻塞状态几小时甚至数天，，除非系统停机。