linux内核线程对信号的处理过程

http://blog.csdn.net/dog250/article/details/5303238

linux中的线程分为用户线程和内核线程，用户线程是标准的线程，完全的自主性，完全的抢占性；但是内核线程就不那么好了，某种意义上没有用户线程那么清闲，这个怎么理解呢？用户线程的编写者只需要实现应用逻辑就可以，至于调度，信号处理等工作完全有内核代劳，用户进程根本不需要操这些心，比如说调度， 在2.6完全可抢占内核之前，内核线程必须显式放弃处理器，否则它将永远不会被抢占，这就给了内核线程的开发者很大的限制，不过谁让他们写的是内核程序呢？应该的！ 
关于调度就不说那么多了，现在看一下信号的处理。linux规定，只有在进程返回用户空间的前夕才处理pending未决的信号，这就产生了一个问题，内 核线程如何处理信号？它永远不会返回用户空间是否意味着它就不能处理信号了，如果真的这样的话，linux内核也就太不灵活了，当然不是这样，这不是 linux的性格。这只是问题之一；还有一个问题就是论坛上很多朋友在问如何杀死内核线程，linux中线程结束有三种方式：1.自己结束；2.异常结 束；3.被信号结束。本质上2也是靠发送信号结束线程的，这样就只剩下两种方式，一个是自主结束一个是靠信号结束，如果内核线程根本就不能处理信号的话，那还谈什么靠信号结束？于是，种种理由迫使内核线程不应该不能处理信号，内核线程虽然没有用户空间，不存在返回用户空间一说，也没有必要就为了内核线程就 更改linux内核信号处理架构，那么唯一的办法就是由内核线程自己处理信号，这个策略和非抢占内核时期由内核线程自己放弃处理器是一样的，毕竟它是内核的东西，多让它作些事情并不多。那么这一切具体是怎么实现的呢？内核线程到底能不能杀死呢？可以先试一下，执行以下命令： 
[root@localhost zhaoy]# ps -e |grep khubd 
然后杀死它，果然，khubd被杀了，那么可以肯定地说，内核线程是可以杀死的！内核线程是怎么被杀死的呢？我们来看一下这个khubd： 
static int hub_thread(void *__unused) 
{ 
         daemonize("khubd");  //这个函数很重要，凡是调用了这个函数该内核线程就放弃了继承的或者sys_fork时分配的用户地址空间mm_struct，而且阻塞了一切信号，包括SIGKILL(-9)信号。 
         allow_signal(SIGKILL);  //又允许了SIGKILL信号 
         do { 
                 hub_events(); 
                 wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list)); 
                 if (current->flags & PF_FREEZE) 
                         refrigerator(PF_FREEZE); 
         } while (!signal_pending(current)); //一轮循环结束就监测是否有信号pending，一旦有就退出循环。（因为只可能是SIGKILL信号） 
         pr_debug ("%s: khubd exiting/n", usbcore_name);  //执行到这里就说明khubd将要退出了，被杀死了 
         complete_and_exit(&khubd_exited, 0); 
} 
以上仅仅用khubd说明一下内核线程怎么处理信号和内核线程被杀的问题，当然还可能有更复杂的控制逻辑，也可能是类似于用户进程的do_signal的逻辑，但是原理一模一样，就不赘述了。 
上面介绍了内核线程处理信号和被杀死的原理，顺带地提了一嘴非抢占内核中内核线程的协作多任务原理（必须自己放弃cpu），这种设计让我觉得很不对称，内 核线程和用户线程没有统一地进行对待，而在solaris里面一切线程都是被统一对待的。这实际上并不是美中不足，而正是linux的灵活性之所在，内核 只提供用户接口，而具体怎么实现用户不必过问，谁要是觉得不好怎么的，完全可以提供一个好的，这就是linux的性格。