关于linux下的信号的问题

信号是否阻塞，只是信号mask的状态，决定对将来收到信号的处理方式。

无论你是否给他信号，这个状态都已经设定。

这个代码先block SIGINT, 然后sleep 10秒等待信号. 10秒后,检查10秒内是否输入了SIGINT信号.(如果输入了,会被block, handler不会被调用, sleep会被中断.). 不管如何,随后立即解除对SIGINT的block. 最后,进入死循环,这时如果ctrl+C, 会发现 handler能被调用.

Linux调度时机主要有：

1、进程状态转换的时刻：进程终止、进程睡眠。

2、当前进程的时间片用完时（current->counter=0）。

3、设备驱动程序。

4、进程从中断、异常及系统调用返回到用户态时。

时机1，进程要调用sleep（）或exit（）等函数进行状态转换，这些函数会主动调用调度程序进行进程调度。

时机2，由于进程的时间片是由时钟中断来更新的，因此，这种情况和时机4是一样的。

时机3，当设备驱动程序执行长而重复的任务时，直接调用调度程序。在每次反复循环中，驱动程序都检查need_resched的值，如果必要，则调用调度程序schedule()主动放弃CPU。

时机4，如前所述，不管是从中断、异常还是系统调用返回，最终都调用ret_from_sys_call（），由这个函数进行调度标志的检测，如果必要，则调用调用调度程序。

从系统调用返回意味着要离开内核态而返回到用户态，而状态的转换要花费一定的时间，因此，在返回到用户态前，系统把在内核态该处理的事全部做完。

在Linux中，进程的运行时间不可能超过分配给他们的时间片，他们采用的是抢占式多任务处理，所以进程之间的挂起和继续运行无需彼此之间的协作。

在一个如linux这样的多任务系统中，多个程序可能会竞争使用同一个资源，在这种情况下，我们认为，执行短期的突发性工作并暂停运行以等待输入的程序，要比持续占用处理器以进行计算或不断轮询系统以查看是否有输入到达的程序要更好。

我们称表现好的程序为nice程序，而且在某种意义上，这个nice 是可以被计算出来的。 *** 作系统根据进程的nice值来决定它的优先级，一个进程的nice值默认为0并将根据这个程序的表现不断变化。长期不间断运行的程序的优先级一般会比较低。

---