信号是典型的异步事件。内核在某个信号出现时有三种处理方式：
- 忽略信号，除了SIGKILL和SIGSTOP信号不能忽略外，其他大部分信号都可以被忽略；
- 捕捉信号，也就是在信号发生时调用一个用户函数，注意不能捕捉SIGKILL和SIGSTOP；
- 执行系统默认动作，注意大多数信号的系统默认动作是终止进程。
当信号产生以后，对信号采取了动作时，称为向进程“递送”了一个信号，在信号产生（generation）和递送（delivery）之间的时间间隔内，称信号是未决的（pending）。
进程可以“阻塞”信号，如果为进程产生了一个阻塞的信号，而且对该信号的动作是调用信号处理函数捕捉该信号，或者是系统默认动作，则会为该进程将此信号保持为未决状态，直到a：对此信号解除了阻塞，或者b：对此信号的动作改为忽略。内核在递送一个原来被阻塞的信号给进程时（而不是产生信号时），才决定对它的处理方式，因此，进程在信号被递送之前仍可改变对该信号的动作。
如果在进程解除某个信号的阻塞之前，该信号发生了多次，则系统可以递送该信号一次或多次。如果递送多次，则称对这些信号进行了排队。但是除非支持POSIX.1实时扩展，否则大多数UNIX并不对信号排队，也就是指递送该信号一次。
如果有多个信号要递送给一个进程，POSIX.1并未规定这些信号的递送顺序。
每个进程都有一个信号屏蔽字，它规定了当前要阻塞的信号集。POSIX.1使用数据类型sigset_t表示一个信号集，进程可以调用sigprocmask来检测和更改当前信号屏蔽字。
对信号的处理是以进程为单位的，也就是说在多线程环境中，信号的处理是进程中所有线程共享的。但是每个线程可以有自己的信号屏蔽字，所以，单个线程可以阻塞某些信号，当某个线程修改了某个信号的处理方式后，所有线程共享这个处理方式的改变。
进程中的信号是递送到单个线程的。如果信号与硬件故障相关，该信号就被递送到引起该事件的线程中去，而其他信号则被递送到任意一个没有阻塞该信号的线程。sigprocmask的行为在多线程中没有定义，线程必须使用相应的pthread_sigmask。
除了使用信号处理函数异步的捕捉信号之外，还可以将这种异步行为变得同步，有两种方法：
- 调用sigwaitinfo、sigtimedwait或sigwait，这些函数会阻塞调用线程，直到信号集set中的某个信号被递送为止，这些函数都会返回递送信号的信息。
- 调用signalfd，它返回一个文件描述符，针对该描述符的read的操作将会阻塞，直到signalfd指定的信号集set中的某个信号递送给调用者为止，此时read返回一个描述该信号的结构。
信号的行为都是过程范围的，一个程序必须在线程之间协调sigaction的任何使用
与硬件环境同步的信号包括SIGFPE，SIGSEGV，SIGTRAP他们被送到引起该硬件状况的线程而绝不会传递给其他线程
不同通过SIGKILL信号来杀死一个线程，也不能通过传送一个SIGTOP信号来停止一个线程
多线程工作时，任何影响进程的信号仍然影响进程，这意味着向进程或向进程内任何线程传送一个SIGKILL信号（pthread_kill）将终止进程，传送一个SIGSTOP信号将导致所有线程停止直到收到SIGCONT信号，这保证了现存的进程处理函数能够继续工作，否则当你传递一个SIGSTOP信号时进程中大多线程可以运行，这也使用其他信号的默认行为如：SIGSEGV，如果不处理，将终止进程并且产生一个核心文件——它不仅仅产生SIGSEGV线程
信号掩码
每个线程有自己的信号掩码。如果线程A因为线程B正在处理SIGFPE信号或因为线程C阻塞了SIGFPE信号而不能处理SIGFPE，这不合适。当一个线程被创建时，他继承了创造它的线程信号掩码，如果想在所有地方屏蔽一个信号，则首先在主线程中屏蔽它
int pthread_sigmask(int how,const sigset_t *set,sigset_t *oset);
pthread_kill
在进程内，一个线程可以通过调用pthread_kill向一个特定的线程包括自己发送信号，不仅需要传递信号数值也要pthread_t，不能向进程外的线程发信号，因为pthread_t只在他创建的进程内有效
int pthread_kill(pthread_t thread,int sig);
pthread_kill发送的信号：
- 如果目标线程被信号屏蔽，他被标记为未解决
- 如果线程正在等待sigwait中的信号，线程收到信号
- 如果线程没哟屏蔽信号，并且没有在sigwait中阻塞，当前信号将被执行
除信号处理函数外，信号也影响进程，使用pthread_kill向一特定线程传递SIGKILL信号将杀死整个进程，不仅仅是特定线程。
raise函数已经传统地被映射到杀死当前进程的函数；即：raise(SIGABRT)通常和kill(getpid()，SIGABRT)一样。对于多线程而言，调用raise的代码可能打算将信号传送到调用的线程而不是一些进程内的线程，raise(SIGABRT)通常和pthread_kill(getpid()，SIGABRT)一样。
内核调用与信号相比，内核是原子的，因此不会被推迟，write函数不会引起死锁。
不能推迟一个可能拥有任何资源的线程（如果该资源可能被一些其他线程在推迟线程被恢复之前要求），如果负责将推迟线程恢复的线程首先要获得资源，结果就是死锁。该禁止包括由你调用的库使用的互斥量如malloc或free或stdio使用的互斥量
sigwait和sigwaitifo
多线程中sigwait总是与异步信号一起工作
pthreads增加了允许线程代码同步的处理异步信号函数：不允许信号在任意点打断一个线程，线程能够选择同步的接收信号通过调用sigwait或某个兄弟函数来实现。
调用sigwait等待的信号必须在调用线程中屏蔽，并且通常在所有线程中屏蔽。
可以创建一个等待一些信号的线程(如：SIGINT)并让他发生时执行一些程序活动，隐含规则是必须在调用sigwait前屏蔽要等待的信号。应该在主线程中，程序的开始屏蔽这些信号，因为信号掩码会继承，所有的线程默认的屏蔽这些信号，这保证信号绝不会被送达除调用sigwait的任何线程。
信号仅仅被交付一次。如果有两个线程在sigwait上阻塞，只有一个线程收到送给进程的信号，这意味着不能让两个独立的子系统使用sigwait捕获SIGINT，这也意味着信号不会被一个线程的sigwait捕获并送到另外线程的信号处理函数
sigwait返回个错误是数字来报告错误，两个兄弟函数用errno机制。两个兄弟函数返回收到信号的实时信息siginfo_t,且sigtimedwait在制定时间间隔内没有收到选定信号返回EAGAIN错误
#include <signal.h>
int sigwait(const sigset_t *set, int *sig);
#ifdef _POSIX_REALTIME_SIGNALS
int sigwaitinfo(const sigset_t *set, siginfo_t *info);
int sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec *timeout);
#endif
sigwait从set中选择一个未决信号(pending)，从进程的未决信号集合中移除该信号，并在sig中返回该信号值。如果set中的所有信号都不是pending状态，则sigwait会阻塞调用它的线程，直到set中的信号变为pending。
为了避免错误动作发生，线程在调用sigwait之前，必须阻塞那些它正在等待的信号，否则行为是未定义的。sigwait函数会自动取消信号集的阻塞状态，直到有新的信号被递送。在返回之前，sigwait将恢复线程的信号屏蔽字。如果信号在sigwait调用的时候没有被阻塞，则在sigwait调用之前会出现一个时间窗，在这个窗口期，某个信号可能在线程调用sigwait之前就被递送了。
sigwait只是取消set中信号的阻塞，其他信号则维持原状态，比如，在sigwait调用之前阻塞了所有信号，而set中只包含了SIGINT，则发送SIGABRT也不会有效果。
如果多个线程在sigwait调用时，等待的是同一个信号，当信号递送的时候，只有一个线程可以从sigwait中返回，具体是那个线程则是未定义的。
如果信号被捕获(进程通过使用sigaction建立了一个信号处理程序)，而且线程正在sigwait调用中等待同一信号，那么这时将由操作系统实现来决定以何种方式递送信号。在这种情况下，操作系统实现可以让sigwait返回，也可以激活信号处理程序，但不可能出现两者皆可的情况。
sigwait成功返回0，失败时返回表示错误的值。
使用sigwait的好处在于它可以简化信号处理，允许把异步产生的信号用同步的方式处理。为了防止信号中断线程，可以把信号加到每个线程的信号屏蔽字中，然后安排专用线程作信号处理。这些专用线程可以进行函数调用，不需要担心在信号处理程序中调用哪些函数是安全的，因为这些函数调用来自正常的线程环境，而非传统的信号处理程序，传统信号处理程序通常会中断线程的正常执行。
除了返回信息方面，sigwaitinfo的行为基本上与sigwait类似。sigwait在sig中返回触发的信号值；而sigwaitinfo的返回值就是触发的信号值，并且如果info不为NULL，则sigwaitinfo返回时，还会在siginfo_t *info中返回更多该信号的信息，siginfo_t的结构体定义如下：
siginfo_t
{
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
int si_trapno; /* Trap number that caused hardware-generated signal (unused on most architectures) */
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending process */
int si_status; /* Exit value or signal */
clock_t si_utime; /* User time consumed */
clock_t si_stime; /* System time consumed */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX.1b signal */
void *si_ptr; /* POSIX.1b signal */
int si_overrun; /* Timer overrun count; POSIX.1b timers */
int si_timerid; /* Timer ID; POSIX.1b timers */
void *si_addr; /* Memory location which caused fault */
long si_band; /* Band event (was int in glibc 2.3.2 and earlier) */
int si_fd; /* File descriptor */
short si_addr_lsb; /*Least significant bit of address (since Linux 2.6.32)*/
}
比如：info->si_signo是信号值；info->si_code是该信号产生的原因
sigtimedwait的行为又与sigwaitinfo的行为类似，只是它多了一个超时参数timeout，也就是可以设置该函数的最大阻塞时间。struct timespec的定义如下：
struct timespec
{
long tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
}
如果该结构体中的成员都置为0的话，则sigtimedwait将会立即返回，此时如果确实有pending信号的话，就返回该信号的信息，否则返回超时错误。
POSIX没有规定，如果timeout为NULL的话sigtimedwait的行为，Linux下，timeout为NULL时，sigtimedwait的行为与sigwaitinfo是一样的。
signalfd
#include <sys/signalfd.h>
int signalfd(int fd, const sigset_t *mask, int flags);
signalfd用来创建一个接收信号的文件描述符，该文件描述符可用于select、poll和epoll。mask参数中指定了调用者希望接收的信号集，一般而言，信号集中的信号在调用signalfd之前，应该使用sigprocmask进行阻塞，这样这些信号就不会按照原来的处理方式进行处理了。注意不能通过signalfd的文件描述符接收SIGKILL或SIGSTOP信号，如果在mask中指定了这俩信号，则会默认忽略掉。
如果fd参数为-1，则signalfd创建新的文件描述符，并将信号集mask与该文件描述符相关联。如果fd不为-1，则fd必须是一个已经存在的signalfd文件描述符，mask用于更新与之对应的信号集。
在Linux2.6.26之前的版本，flags参数是无用的，必须置为0。从Linux2.6.27开始，可以在flags中指定下面的值以改变signalfd的行为：
SFD_NONBLOCK：在新创建的文件描述符上设置O_NONBLOCK文件状态标志；
SFD_CLOEXEC：在新建的文件描述符上设置FD_CLOEXEC标志。
注意上面的两个标志，都是针对新建描述符而言的（fd为-1），如果是一个已经存在的描述符，设置这两个标志都没有作用（已通过程序验证）。
signalfd创建描述符支持下列操作：
read：如果mask中的一个或多个信号是未决状态（pending）的话，则read将会在其buffer参数中返回一个或多个描述信号的signalfd_siginfo结构。read操作尽可能多的返回未决信号，并将其信息填充到buffer。buffer至少应该是sizeof(struct signalfd_siginfo) 个字节，read的返回值就是读取的字节数。
在read之后，read返回的信号就被消费掉了，不再处于未决状态（也就是不能再由信号处理函数捕捉，也不能使用sigwaitinfo接收）。
如果mask中的信号都不是未决状态，若文件描述符置为非阻塞的话，read返回EAGAIN错误，否则read会一直阻塞，直到mask中的信号产生。
select、poll、epoll等：如果mask中有一个或多个信号处于未决状态的话，则这些文件描述符就是可读的，从而可以使得select、poll或者epoll返回。
close：当不再需要该文件描述符时，应该使用close关闭。与其他文件描述符一样，如果底层signalfd对象关联的所有文件描述符都关闭之后，则该对象的资源就会被内核释放掉
结构体signalfd_siginfo的定义如下：
struct signalfd_siginfo
{
uint32_t ssi_signo; /* Signal number */
int32_t ssi_errno; /* Error number (unused) */
int32_t ssi_code; /* Signal code */
uint32_t ssi_pid; /* PID of sender */
uint32_t ssi_uid; /* Real UID of sender */
int32_t ssi_fd; /* File descriptor (SIGIO) */
uint32_t ssi_tid; /* Kernel timer ID (POSIX timers) */
uint32_t ssi_band; /* Band event (SIGIO) */
uint32_t ssi_overrun; /* POSIX timer overrun count */
uint32_t ssi_trapno; /* Trap number that caused signal */
int32_t ssi_status; /* Exit status or signal (SIGCHLD) */
int32_t ssi_int; /* Integer sent by sigqueue(3) */
uint64_t ssi_ptr; /* Pointer sent by sigqueue(3) */
uint64_t ssi_utime; /* User CPU time consumed (SIGCHLD) */
uint64_t ssi_stime; /* System CPU time consumed (SIGCHLD) */
uint64_t ssi_addr; /* Address that generated signal (for hardware-generated signals) */
uint8_t pad[X]; /* Pad size to 128 bytes (allow for additional fields in the future) */
};
该结构体中的每个成员都类似于结构体siginfo_t中的成员。对于一个特定的信号，read返回的signalfd_siginfo结构体中，并非所有的成员都是有效的；具体哪些成员是有意义的，可以通过成员ssi_code来检测，该成员类似于siginfo_t中的si_code成员。
fork之后，子进程拥有了父进程的signalfd文件描述符的副本，在子进程的文件描述符上调用read，将会返回子进程的未决信号。
类似于其他文件描述符，除非设置了close-on-exec标志，否则signalfd文件描述符在execve之后还是保持打开的，在execve之前可读的信号，在新的进程中依然可读。
在多线程环境中，signalfd文件描述符与标准的多线程中信号的语义是一样的。也就是说，当一个线程读取signalfd文件描述符时，它会读取到针对该线程的信号，以及针对整个进程的信号。
调用signalfd成功时，返回一个signalfd文件描述符，该描述符要么是一个新的signalfd描述符（fd为-1的情况下），要么就是fd（fd已经是个有效的signalfd描述符的情况下）。
调用signalfd错误时，返回-1，并设置相应的errno。
一个进程可以创建多个signalfd文件描述符，这样可以在不同的signalfd描述符上等待不同的信号。如果多个文件描述符中的mask上具有同一个信号，当信号发生时，所有描述符都变得可读，可以从任意一个描述符读取该信号。这种情况下，如果使用select、poll或者epoll等待这些signalfd描述符，则这些描述符都会变成可读的，从其中之一读取之后，该信号就被消费掉，读取其他的描述符就会阻塞，所以要避免这种情况
SIGEV_THREAD
当使用aio_read或aio_write时初始化一台异步设备读或写时，程序员指定一个struct aiocb，其中包含了一个struct sigevent成员，接受struct sigevent的其他函数包括timer_create(他创造一个进程范围内的定时器)和sigqueue（他将信号送入进程队列）。
struct sigevent提供了一种允许程序员指定一个信号是否产生以及如果产生应该使用时什么信号数字的“通知机制”。pthreads增设了一个被称为SIGEV_THREAD的新通知机制，该通知机制使得信号通知函数向线程气势函数一样运行。
SIGEV_THREAD通知函数可能无法在一个新的线程中实际运行。系统可以排队SIGEV_THREAD事件，在一些内部“服务线程”连续调用起始函数，这种差别对于应用程序而言很难有效的区分，使用系统服务线程要很小心的为通知线程指定属性——调度策略，优先级，竞争范围，最小栈空间。
对于传统的信号机制如：setitimer，SIGCHLD，SIGINT等，SIGEV_THREAD特性不可用。
timer_t timer_id;
struct itimerspec ts;
struct sigevent se;
se.sigev_notify=SIGEV_THREAD;
se.sigev_value.sival_ptr=&timer_id;
se.sigev_notify_function=timer_fun;//一个指向线程起始函数的指针
//期望的线程创建属性的线程属性对象---pthread_attr_t，如为空，则与将deatchstate属性设置为PTHREAD_CREATE_DETACHED一样
//创建通知线程，这样避免内存泄漏，因为线程标识符不是对任何其他线程来讲都可得到所以说PTHREAD_CREATE_JOINABLE结果是不可知的
se.sigev_notify_attributes=NULL;
ts.it_value.tv_sec=5;
ts.it_value.tv_nsec=0;
ts.it_interval.tv_sec=5;
ts.it_interval.tv_nsec=0;
timer_create(CLOCK_REALTIME,&se,&timer_id);
timer_settime(timer_id,0,&ts,0);
