linux的signal生成与deliver的理解。
要理解，当然要从数据结构去理解以下代码来自<linux/sched.h> <asm-generic/signal.h> <linux/signal.h>。
每一个process的task descriptor task_struct中跟signal有关的field：
task_struct{
....
struct signal_struct *signal;
struct sighand_struct *sighand;
struct sigpending pending; //private pending signal for every LWP
sigset_t blocked, real_blocked;
....
}
struct sigpending{
struct list_head list;
sigset_t signal; //32位或者64位，每一位对应一个signal类型。
}
struct signal_struct *signal; //存储了shared signal pending
struct signal_struct{
....
struct sigpending pending; //shared signal pending
....
}
struct sighand_struct *sighand;
struct sighand_struct { //当信号到来的时候，需要调用signal_handler进行处理。
atomic_t count;
struct k_sigaction action[_NSIG];
spinlock_t siglock;
wait_queue_head_t signalfd_wqh;
};
简易对signal的理解：
signal的作用：
1 进程间通信。比如说kill，如果权限足够，那么就会给对应的进程发送kill相关信号。下面具体研究各个信号是干什么用的。
2 将中断以signal的形式反应给应用程序，并进行相应的操作。
signal的实现：
现在假设是sigset_t 为32位的类型，并且一般的话，系统中也定义了32中signal类型，一个类型对应一位。
1 signal generation
signal generation是相对于signal deliver来说的。
具体的动作为：
- 现在来了一个信号，首先task_struct中sigset_t blocked.没有将当前这个信号block住。
- 目标进程如果不正在运行，signal就会被放到pending中。
- 当kernel调度进程运行的时候，即是从Kernel mode转向User mode的时候，检查被pending的signal，并调用相应的signal-handler进行处理。
附上Understanding the linux kernel对信号的总结，下面全是经典：
/* Importent
At any time pending signal of a given type may exist for a process; additional pending signals of the same type to the same process
are not queued but simply discarded.
In general, a signal may remain pending for an unpredictable amount of time. The following factors must be
taken into consideration:
1 Signals are usually delivered only to the currently running process (that is, to the current process).
2 Signals of a given type may be selectively blocked by a process (see the later section "Modifying the
Set of Blocked Signals"). In this case, the process does not receive the signal until it removes the
block.
3 When a process executes a signal-handler function, it usually masks the corresponding signali.e., it
automatically blocks the signal until the handler terminates. A signal handler therefore cannot be
interrupted by another occurrence of the handled signal, and the function doesn't need to be reentrant.
Importent */
//底下稍微不重要
Although the notion of signals is intuitive, the kernel implementation is rather complex. The kernel must:
Remember which signals are blocked by each process. •
When switching from Kernel Mode to User Mode, check whether a signal for a process has arrived.
This happens at almost every timer interrupt (roughly every millisecond).
•
Determine whether the signal can be ignored. This happens when all of the following conditions are
fulfilled:
The destination process is not traced by another process (the PT_PTRACED flag in the
process descriptor ptrace field is equal to 0).
[*]
[*]
If a process receives a signal while it is being traced, the kernel stops the
process and notifies the tracing process by sending a SIGCHLD signal to it.
The tracing process may, in turn, resume execution of the traced process by
means of a SIGCONT signal.
♦
The signal is not blocked by the destination process. ♦
The signal is being ignored by the destination process (either because the process explicitly
ignored it or because the process did not change the default action of the signal and that
action is "ignore").
♦
•
Handle the signal, which may require switching the process to a handler function at any point during
its execution and restoring the original execution context after the function returns.
对Signal的类型的总结,等到使用到的时候，自然而然了解它们的作用了：
Standard Signals
Linux supports the standard signals listed below. Several signal numbers are architecture dependent, as indicated in the "Value" column. (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for i386, ppc and sh, and the last one for mips. A - denotes that a signalis absent on the corresponding architecture.)
First the signalsdescribed in the original POSIX.1-1990 standard.
| Signal | Value | Action | Comment |
| SIGHUP | |||
| or death of controlling process | |||
| SIGINT | 2 | Term | Interrupt from keyboard |
| SIGQUIT | 3 | Core | Quit from keyboard |
| SIGILL | 4 | Core | Illegal Instruction |
| SIGABRT | 6 | Core | Abort signal from abort(3) |
| SIGFPE | 8 | Core | Floating point exception |
| SIGKILL | 9 | Term | Kill signal |
| SIGSEGV | 11 | Core | Invalid memory reference |
| SIGPIPE | 13 | Term | Broken pipe: write to pipe with no readers |
| SIGALRM | 14 | Term | Timer signal from alarm(2) |
| SIGTERM | 15 | Term | Termination signal |
| SIGUSR1 | 30,10,16 | Term | User-defined signal 1 |
| SIGUSR2 | 31,12,17 | Term | User-defined signal 2 |
| SIGCHLD | 20,17,18 | Ign | Child stopped or terminated |
| SIGCONT | 19,18,25 | Cont | Continue if stopped |
| SIGSTOP | 17,19,23 | Stop | Stop process |
| SIGTSTP | 18,20,24 | Stop | Stop typed at tty |
| SIGTTIN | 21,21,26 | Stop | tty input for background process |
| SIGTTOU | 22,22,27 | Stop | tty output for background process |
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
Next the signalsnot in the POSIX.1-1990 standard but described in SUSv2 and POSIX.1-2001.
| Signal | Value | Action | Comment |
| SIGBUS | |||
| SIGPOLL | Term | Pollable event (Sys V). Synonym of SIGIO | |
| SIGPROF | 27,27,29 | Term | Profiling timer expired |
| SIGSYS | 12,-,12 | Core | Bad argument to routine (SVr4) |
| SIGTRAP | 5 | Core | Trace/breakpoint trap |
| SIGURG | 16,23,21 | Ign | Urgent condition on socket (4.2BSD) |
| SIGVTALRM | 26,26,28 | Term | Virtual alarm clock (4.2BSD) |
| SIGXCPU | 24,24,30 | Core | CPU time limit exceeded (4.2BSD) |
| SIGXFSZ | 25,25,31 | Core | File size limit exceeded (4.2BSD) |
Up to and including Linux 2.2, the default behaviour for SIGSYS, SIGXCPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). (On some other Unices the default action for SIGXCPU and SIGXFSZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, terminating the process with a core dump.
Next various other signals.
| Signal | Value | Action | Comment |
| SIGIOT | |||
| SIGEMT | 7,-,7 | Term | |
| SIGSTKFLT | -,16,- | Term | Stack fault on coprocessor (unused) |
| SIGIO | 23,29,22 | Term | I/O now possible (4.2BSD) |
| SIGCLD | -,-,18 | Ign | A synonym for SIGCHLD |
| SIGPWR | 29,30,19 | Term | Power failure (System V) |
| SIGINFO | 29,-,- | A synonym for SIGPWR | |
| SIGLOST | -,-,- | Term | File lock lost |
| SIGWINCH | 28,28,20 | Ign | Window resize signal (4.3BSD, Sun) |
| SIGUNUSED | -,31,- | Term | Unused signal (will be SIGSYS) |
(Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)
SIGEMT is not specified in POSIX.1-2001, but nevertheless appears on most other Unices, where its default action is typically to terminate the process with a core dump.
SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by default on those other Unices where it appears.
SIGIO (which is not specified in POSIX.1-2001) is ignored by default on several other Unices.
