linux有哪些信号不会被阻塞

1. 信号在内核中的表示我们知道了信号产生的各种原因，而实际执行信号处理的动作，叫做信号递达（Delivery）。信号从产生到递达之间的状态，称为信号未决（Pending）。进程可以选择阻塞（Block）某个信号。被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞，才执行递达的动作。 注意，阻塞和忽略是不同的，只要信号被阻塞就不会递达，而忽略是在递达之后可选的一种处理动作。每个信号都有两个标志位分别表示阻塞和未决，，还有一个函数指针表示处理动作，信号产生时，内核在进程控制块中设置该信号的未决标志，直到信号递达才清除该标志。 SIGHUP信号未阻塞也未产生过，当它递达时执行默认处理动作。 SIGINT信号产生过，但正在被阻塞，所以暂时不能递达。虽然它的处理动作是忽略，但在没有解除阻塞之前不能忽略这个信号，因为进程仍有机会改变处理动作之后再解除阻塞。SIGQUIT信号未产生过，一旦产生SIGQUIT信号将被阻塞，它的处理动作是用户自定义函数sighandler。 如果在进程解除对某信号的阻塞之前这种信号产生过多次，将如何处理？ POSIX.1允许系统递送该信号一次或多次。Linux是这样实现的：常规信号在递达之前产生多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里。 从上图来看，每个信号只有一个bit的未决标志，非0即1，不记录该信号产生了多少次，阻塞标志也是这样表示的。因此，未决和阻塞标志可以用相同的数据类型sigset_t来存储，sigset_t称为信号集，这个类型可以表示每个信号的“有效”或“无效”状态，在阻塞信号集中“有效”和“无效”的含义是该信号是否被阻塞，而在未决信号集中“有效”和“无效”的含义是该信号是否处于未决状态。 2. 信号集 *** 作函数 sigset_t类型对于每种信号用一个bit表示“有效”或“无效”状态，至于这个类型内部如何存储这些bit则依赖于系统实现，从使用者的角度是不必关心的，使用者只能调用以下函数来 *** 作sigset_t变量，而不应该对它的内部数据做任何解释，比如用printf直接打印sigset_t变量是没有意义的。 #include <signal.h>int sigemptyset(sigset_t *set) ----- 初始化set指向的信号集，使其中所有信号的对应bit清零，表示该信号集不包含任何有效信号.int sigfillset(sigset_t *set)---- 初始化set所指向的信号集，使其中所有信号的对应bit置位,表示该信号集的有效信号包括系统支持的所有信号。int sigaddset(sigset_t *set, int signo)int sigdelset(sigset_t *set, int signo)int sigismember(const sigset_t *set, int signo)注意，在使用sigset_t类型的变量之前，一定要调用sigemptyset或sigfillset做初始化，使信号集处于确定的状态。3. sigprocmask调用函数sigprocmask可以读取或更改进程的信号屏蔽字。如果oset是非空指针，则读取进程的当前信号屏蔽字通过oset参数传出。如果set是非空指针，则更改进程的信号屏蔽字，参数how指示如何更改。如果oset和set都是非空指针，则先将原来的信号屏蔽字备份到oset里，然后根据set和how参数更改信号屏蔽字。假设当前的信号屏蔽字为mask，下表说明了how参数的可选值。

阻塞 *** 作是指在执行设备 *** 作时，若不能获得资源，则挂起进程直到满足可 *** 作的条件后再进行 *** 作。被挂起的进程进入睡眠状态，被从调度器的运行队列移走，直到等待的条件被满足。而非阻塞 *** 作的进程在不能进行设备 *** 作时，并不挂起，它要么放弃，要么不停地查询，直至可以进行 *** 作为止。

驱动程序通常需要提供这样的能力：当应用程序进行read（）、write（）等系统调用时，若设备的资源不能获取，而用户又希望以阻塞的方式访问设备，驱动程序应在设备驱动的xxx_read（）、xxx_write（）等 *** 作中将进程阻塞直到资源可以获取，此后，应用程序的read（）、write（）等调用才返回，整个过程仍然进行了正确的设备访问，用户并没有感知到；若用户以非阻塞的方式访问设备文件，则当设备资源不可获取时，设备驱动的xxx_read（）、xxx_write（）等 *** 作应立即返回，read（）、write（）等系统调用也随即被返回，应用程序收到-EAGAIN返回值。

在阻塞访问时，不能获取资源的进程将进入休眠，它将CPU资源“礼让”给其他进程。因为阻塞的进程会进入休眠状态，所以必须确保有一个地方能够唤醒休眠的进程，否则，进程就真的“寿终正寝”了。唤醒进程的地方最大可能发生在中断里面，因为在硬件资源获得的同时往往伴随着一个中

断。而非阻塞的进程则不断尝试，直到可以进行I/O。

---