1.linux内核2.6，SIGRTMIN之前的信号仍然是不可靠的么？——即丢失而且进程每次处理信号后，就将对信号的响应设置为默认动作 
2.就是说，我kill(pid,SIGKILL)发出去的信号仍然可能丢失？ 
3.SIGRTMIN和SIGRTMAX之间的可靠信号，进程每次处理信号后，就不会把对信号的响应设置为默认动作了吧？ 

Linux下也许不会设置默认的处理方式，但是在大多数源于系统V的系统（比如AIX 5.3）上，确实会重置为默认的处理方式。
APUE上有详细描述。如果缺省行为符合楼主的要求，使用signal函数，否则建议使用sigaction函数。

1.好像是这样，但是不确定是不是 2.6以前都这样，但是至少APUE里写的时候，用的内核是这样。

2.编号为1 ~ 31的信号为传统UNIX支持的信号，是不可靠信号,SIGKILL是不可靠。
因此，早期unix下的不可靠信号主要指的是进程可能对信号做出错误的反应连同信号可能丢失。 
Linux支持不可靠信号，但是对不可靠信号机制做了改进：在调用完信号处理函数后，不必重新调用该信号的安装函数（信号安装函数是在可靠机制上的实现）。因此，Linux下的不可靠信号问题主要指的是信号可能丢失。 而31之后的信号是新添加的，这些信号在信号处理函数的结尾 也不必再调用一次信号安装函数。同时，由signal()安装的实时信号支持排队，同样不会丢失。

2楼,3楼,说32以前的信号不可靠,并不是说系统会不会在调用一次信号处理函数后会重置为默认的处理方式. APUE里这么写,但尽信书不如无书,APUE里写的内容是80年代末90年代初的内容了. 
现在所说的信号不可靠, 是因为linux对32以前的信号没有排队功能,也就是说当其它进程在很短的时间内连续往一个进程发了好几个一样的信号, 如果在这期间该进程一直没有调度到的话,该进程最终只能收到一个信号, 也就是说后面的那几个信号丢失了. 32以后的信号添加了排队功能,所以不会丢失.
举个简单的例子,你一个进程创建了100个子进程, 然后在外部用kill同时把所有的子进程都杀掉, 那么父进程并不能收到100个SIGCHLD信号.