原文地址：http://blogold.chinaunix.net/u1/48788/showart.php?id=2270724
2) 在信号处理过程返回前，进程会对相同信号的标志进行屏蔽；
3) 父进程会把当前的信号屏蔽标志位信息传递给它派生的子进程。
信号本质
信号是在软件层次上对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是异步的，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。
信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。
信号来源
信号事件的发生有两个来源：硬件来源(比如我们按下了键盘或者其它硬件故障)；软件来源，最常用发送信号的系统函数是kill, raise, alarm和setitimer以及sigqueue函数，软件来源还包括一些非法运算等操作。
二、信号的种类
可以从两个不同的分类角度对信号进行分类：（1）可靠性方面：可靠信号与不可靠信号；（2）与时间的关系上：实时信号与非实时信号。在《Linux环境进程间通信（一）：管道及有名管道》的附1中列出了系统所支持的所有信号。
1、可靠信号与不可靠信号
"不可靠信号"
Linux信号机制基本上是从Unix系统中继承过来的。早期Unix系统中的信号机制比较简单和原始，后来在实践中暴露出一些问题，因此，把那些建立在早期机制上的信号叫做"不可靠信号"，信号值小于SIGRTMIN(Red hat 7.2中，SIGRTMIN=32，SIGRTMAX=63)的信号都是不可靠信号。这就是"不可靠信号"的来源。它的主要问题是：
- 进程每次处理信号后，就将对信号的响应设置为默认动作。在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用signal()，重新安装该信号。
- 信号可能丢失，后面将对此详细阐述。
因此，早期unix下的不可靠信号主要指的是进程可能对信号做出错误的反应以及信号可能丢失。
Linux支持不可靠信号，但是对不可靠信号机制做了改进：在调用完信号处理函数后，不必重新调用该信号的安装函数（信号安装函数是在可靠机制上的实现）。因此，Linux下的不可靠信号问题主要指的是信号可能丢失。
"可靠信号"
随着时间的发展，实践证明了有必要对信号的原始机制加以改进和扩充。所以，后来出现的各种Unix版本分别在这方面进行了研究，力图实现"可靠信号"。由于原来定义的信号已有许多应用，不好再做改动，最终只好又新增加了一些信号，并在一开始就把它们定义为可靠信号，这些信号支持排队，不会丢失。同时，信号的发送和安装也出现了新版本：信号发送函数sigqueue()及信号安装函数sigaction()。POSIX.4对可靠信号机制做了标准化。但是，POSIX只对可靠信号机制应具有的功能以及信号机制的对外接口做了标准化，对信号机制的实现没有作具体的规定。
信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()。
注：不要有这样的误解：由sigqueue()发送、sigaction安装的信号就是可靠的。事实上，可靠信号是指后来添加的新信号（信号值位于SIGRTMIN及SIGRTMAX之间）；不可靠信号是信号值小于SIGRTMIN的信号。信号的可靠与不可靠只与信号值有关，与信号的发送及安装函数无关。目前linux中的signal()是通过sigation()函数实现的，因此，即使通过signal（）安装的信号，在信号处理函数的结尾也不必再调用一次信号安装函数。同时，由signal()安装的实时信号支持排队，同样不会丢失。
对于目前linux的两个信号安装函数:signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数（对所有信号这一点都成立），而经过signal安装的信号却不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。
2、实时信号与非实时信号
早期Unix系统只定义了32
下载文件
wget http://www.cmake.org/files/v2.8/cmake-2.8.5.tar.gz
编译安装
tar zxvf cmake-2.8.5.tar.gz
cd cmake-2.8.5
.boostarp
make
make install
cmake --version
二、 安装配置mysql
下载文件
wget http://dev.mysql.com/get/Downloads/MySQL-5.5/mysql-5.5.14.tar.gz/from/ftp://ftp.ntu.edu.tw/pub/MySQL/
设置LINUX自动匹配环境变量
1.$su #su进入root
#vi /etc/profile
在文件末尾加上下列语句：
PATH=$PATH:/sbin ＃在PATH变量后追加/sbin目录
export PATH=$PATH:/sbin ＃设置变量为全局的
保存并退出。
退出root并在终端运行
$source /etc/profile #该命令的作用是重新执行刚修改的初始化文件，使之立即生效，而不必注销并重新登好了在终端中输入ifconfig
创建用户和组
groupadd mysql // 建一个msyql的用户和组
useradd -g mysql mysql -s /usr/sbin/nologin
mkdir /usr/local/mysql // 创建目录
mkdir /usr/local/mysql/data // 数据仓库目录
安装mysql
刚写了程序发现点问题。假设一个程序有多个线程，有一个全局互斥锁M....在某线程A获得锁以后，这个时候来了一个信号(假设这个信号注册了自己的处理程序)，那么需要进入信号处理程序，进入以后信号处理处理程序也要获得这个锁。问题来了？会死锁么？
我们知道同一线程如果重复申请同一个互斥锁那么必然会死锁？这里问题转换到信号处理函数跟之前的线程A会是同一个线程上下文么（即是同一个线程么）？我们试验一下。实验之前需要明确几点：
1.根据APUE 12.8，进程的处理函数与处理方式是进程中所有线程共享的。
2.根据APUE 12.8，如果进程接收到信号，该信号只会被递送到某一个单独线程。一般情况下由那个线程引起信号则递送到那个线程。如果没有线程引发信号，信号被发送到任意线程。
上面程序首先共享了一个共同的SIGUSR1信号处理函数，主控线程A然后产生一个线程B，线程B首先获得全局互斥锁，然后运行一个长5秒的程序，然后释放锁。在B运行了大概2秒的时候，线程A给本进程(注意是进程，而不是某线程)发送一个SIGUSR1信号。此时，会死锁么？编译运行看结果.
连续运行了5次，都没有死锁。我们分析一下，当进程接收信号时，进程把信号并没有递送给线程B(因为没有产生死锁)，也就是说是不是这个递送过程被优化了？还是我们真的运气好？需要进一步探查。接下来我们指定把信号递送给线程B，看会不会死锁。
接下来编译运行：
不出意料，果然死锁了。
也就是说，关于线程与信号处理函数获得同一把互斥锁的问题，关键是看信号被递送给了那个线程，如果信号是被递送给了获得锁的那个线程，就会死锁，如果不是之前获得锁的线程，程序就继续运行。