linux内核线程对信号的处理过程
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)
关于调度就不说那么多了，现在看一下信号的处理。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)
{
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1274043
