芜湖市2015年平均工资:从kernel原始码的角度分析signal的错误用法和注意事项(zt)

！声明： 按照Linux的习惯， 我的这篇文件也遵循GPL 协议： 你能随意应用并修改本文件,必须发布你的修改,使其他人能获得一份Copy，尤其是给我一份Copy！ 我的mail ：
bob_zhang2004@163.com
|
zhanglinbao@gmail.com
均可。欢迎论坛转载！ 目前有些内容已在
www.linuxforum.net
中进行过讨论，能前往：
http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxK&Number=607800&page=0&view=&sb=&o=&fpart=&vc=1
   和  
http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxK&Number=607228&page=1&view=collapsed&sb=5&o=7&fpart
=   欢迎大家继续讨论，以便文件更加完善！ 多谢！周末愉快！                                 
--bob
读这份文件之前，建议先浏览一下 《Unix Advanced Programming》里面的signal一章和下面这份出自IBM论坛的文章：进程间通信 信号（上）
http://www-128.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html
  ，和 进程间通信 信号（下）
http://www-128.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html
该作者写了一个系列的进程间通信的文章， 我只是希望对该篇作个补充！
因为他们都没有从原始码的角度分析，所以我尝试了一下把上层应用和kernel实现代码分析结合起来，这样使用者才可能真正的理解signal的用法和原理！
目前介绍signal理论和用法书不少，缺点是只介绍其用法，非常深奥拗口，不容易理解；  而介绍kernel原始码的书，侧重于代码分析，不讲实际应用！
我就想到如果把两者结合起来，对上层使用signal函数的用户必然能知起所以然了，而且只要顺着我的代码注释大概粗读一下源码就能理解 signal的特性和用法及你碰到的种种疑惑和不解了。
如果你对signal的特性和用法有什么疑惑的话， 如果对kernel也感兴趣的话， 就能继续读源码 ， 把这篇文章加以补充和完善！  前提是遵守上面的声明！

因为工作的需要，用了2天的时间周详的读了一下 linux kernel 2.4.24 版本的signal方面的原始码，收获不小， 因为以前发现看>的时候 ，不知道是大师的话太深奥，还是中文版太烂，有的东西就是理解不了，象吃满头嗫住了，非常是不爽，总觉得心里不踏实。看看源码才真正明白什么是信号，及他的kernel流程，所以建议大家对某个系统调用，函数什么的，如果存在疑惑和不理解的，强烈建议读读源码，粗读也非常不错，关键要由参考书领着读，比如> 就非常不错。
有的时候看着一个系统调用成堆的手册页，还真不如看看他的实现来得更快， 当然两下对照着看就快了。   
另外提醒大家 > 可不是 《Linux Advanced Programming》啊！尽信书不如无书 ......
在此通过阅读源码，弄清晰了5个问题，每个问题我都给出了结论，当然这些结论肯定是正确的，至少《Unix Advanced Programming》是这样认为的， 我只是从kernel的角度是验证他的正确性(简单的写了几个测试程式，以验证kernel的做法)，而且也归纳了 一些结论，比如怎么避免 Zobie进程 等。  相信对大家会有价值，也能mail讨论！或上相应的论坛！
首先总结一下：在PC linux（RHT 9.0 + kernel-2.4.24) 键盘产生的信号：
Ctrl + c     SIGINT(2) terminate ，以前我总想当然以为是 SIGTERM(15)！
Ctrl + ＼ SIGQUIT(3) terminate
Ctrl + z SIGTSTP(20) 挂起进程
对于一般应用：
挂起一个进程： kill(pid, SIGSTOP)   或 kill(pid,SIGTSTP) , 或 SIGTTIN , SIGTTOU 信号
恢复一个进程  kill(pid,SIGCONT);  
杀死所有的符合某个名字的进程 ：比如killall  curl ，发送的是SIGTERM 信号
强制杀死某个进程 kill ?9 curl  ,发送的是SIGKILL 信号， 在kernel中，SIGKILL和SIGSTOP是不能被忽略的
....
剩下的大家都清晰了，这里就不罗嗦了。
子进程结束时候发给父进程的信号：   SIGCHLD ，这个比较特别 ， 且看下面3>的论述
Agenda ：
1>不可靠的信号
2>Zombie进程（僵尸进程）和signal
3>特别的SIGCHLD 信号
4>信号和进程的关系 ，进程的需求
5>pause() 和 signal
6>关于信号的技巧
1> 不可靠的信号（linux继承Unix的结果，考虑兼容性） ，  和可靠的信号（主要就是信号能排队处理，信号不丢失，linux自己的，但大家似乎用的不多）
什么是不可靠的信号：简单的说，就是当你向一个进程发送 singal( 1～31，注意这里讨论是 1～31 )的时候 ， 当进程还没有处理该信号（这时候叫pending，未决信号)或是正在调用信号处理函数的时候，  进程又收到了一个同样的信号 ， kernel会把第二个信号丢弃，或叫和一个信号合并,这样的信号就是 不可靠的信号  ，具体正方面的比较权威的解释请参考
http://www-128.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html
,这篇文章对于信号理论介绍的非常周详清晰明白， 个人认为比《Unix advanced Programming》要更好！
系统实现是这样的：
==>  kernel/signal.c  
int send_sig_info(int sig, struct siginfo *info, struct task_struct *t)
{
.............................................
/*  
  如果当前进程的未决信号集中已包括了这个信号，就不重新注册后来目前的同样的信号了，  
  据个例子：  给进程发了 SIGTERM 信号 ， 不过kernel还没有来得及处理（进程只有在kernel空间即将返回道用户空间的时候，
  kernel才会检测pending信号 ,然后才会调用do_signal()函数去处理）
  这个时候又发了一个SIGTERM，那么第二个SIGTERM 肯定要被cut掉了。
*/
if (sig pending.signal, sig))  //SIGRTMIN 是分水岭 ， 小于他的都是不可靠的信号，否则就是实时信号
  goto out;  //跳出了正常执行的范围
....................................................
}
！正确的： 1～31都是不可靠的信号！ SIGRTMIN ～SIGRTMAX都是可靠的信号！
以前大家有个误区：
！误区1>
以为不可靠的信号，是指 给进程发了一个信号（之前没有发过），那么这个信号可能丢失，也就是进程收不到
这样的理解是错误的， 根据上面的定义 ， 应该是”一个信号发了多遍，后来的信号丢失了， 而不是第一个丢了“。
具体的原因能参照上面的代码分析，就一目了然，还能看 《unix advanced programming 》，不过我觉得他讲的都是老的Unix ，对Linux只能是参考而已！
！误区2>
signal() 发送的是不可靠的信号 ，而 sigaction()发送的是可靠的信号


只要是1－31的信号，他就是不可靠的信号。 无论在注册信号处理函数的时候用的是sigaction() ，还是signal() ，只要你发送的信号 是  1-31，那么就是不可靠的信号。中国有句俗语叫”烂泥扶不上墙“，我看放在这里挺合适！
signal（）和 sigaction()的差别到底在哪里呢？   通过对比一看便知：
   对于signal() ，他的kernel实现函数，也叫系统调用服务历程sys_signal()
==>kernel/signal.c
asmlinkage unsigned long
sys_signal(int sig, __sighandler_t handler)
{
struct k_sigaction new_sa, old_sa;
int ret;
new_sa.sa.sa_handler = handler;
new_sa.sa.sa_flags = SA_ONESHOT | SA_NOMASK;
    //SA_ONESHOT：当执行一次信号处理程式后， 马上恢复为SIG_DFL ，
    //SA_NOMASK : 表示在信号处理函数执行期间，不屏蔽的当前正在处理的那个信号
ret = do_sigaction(sig, &new_sa, &old_sa);   //sys_sigaction 也调用这个函数
return ret ? ret : (unsigned long)old_sa.sa.sa_handler;
}
而sigaction（）函数的kernel实现是： sys_sigaction()
==>arch/i386/kernel/signal.c
asmlinkage int
sys_sigaction(int sig, const struct old_sigaction *act,struct old_sigaction *oact)
{
struct k_sigaction new_ka, old_ka;
int ret;
if (act) {
  old_sigset_t mask;
  if (verify_area(VERIFY_READ, act, sizeof(*act)) ||
      __get_user(new_ka.sa.sa_handler, &act->sa_handler) ||
      __get_user(new_ka.sa.sa_restorer, &act->sa_restorer))
   return -EFAULT;
  __get_user(new_ka.sa.sa_flags, &act->sa_flags);
  __get_user(mask, &act->sa_mask);
  siginitset(&new_ka.sa.sa_mask, mask);
}
ret = do_sigaction(sig, act ? &new_ka : NULL, oact ? &old_ka : NULL);//都调的这个函数
if (!ret && oact) {
  if (verify_area(VERIFY_WRITE, oact, sizeof(*oact)) ||
      __put_user(old_ka.sa.sa_handler, &oact->sa_handler) ||
      __put_user(old_ka.sa.sa_restorer, &oact->sa_restorer))
   return -EFAULT;
  __put_user(old_ka.sa.sa_flags, &oact->sa_flags);
  __put_user(old_ka.sa.sa_mask.sig[0], &oact->sa_mask);
}
return ret;
}
signal()和sigaction() 都是用do_signaction()来包装的， 都是用 struct sigaction()这个结构体的，差别在下面标出来了
struct sigaction {
__sighandler_t sa_handler;  //2// typedef void (*__sighandler_t)(int);  signal()和sigaction()函数都需求要户提供信号处理函数
unsigned long sa_flags; //signal()函数默认就用 SA_ONESHOT | SA_NOMASK;  //sigaction()要由用户自己指定！
void (*sa_restorer)(void); //没用了
sigset_t sa_mask;    //执行信号处理函数的时候要阻塞的信号，signal()使用默认的，就屏蔽正处理的信号，其他的不屏蔽，sigaction() 需求用户自己指定!
};
讨论时间： 读到这里我有个疑问：sys_signal()函数明明把 sa_flags = SA_ONESHOT | SA_NOMASK; 而且在kernel执行信号处理函数之前，他会检查SA_ONESHOT标志 ，如果有这个标志，  就把sa_handler = SIG_DFL ,如果是这样的话， 我们需要反复注册某个信号的处理函数才行啊， 不过事实上，我们并没有这样作，而且程式运行的非常好！
Kernel的signal()函数实现代码如下：

==>arch/i386/kernel/signal.c
static void
handle_signal(unsigned long sig, struct k_sigaction *ka,
       siginfo_t *info, sigset_t *oldset, struct pt_regs * regs)
{
...........................................................
/* Set up the stack frame */
if (ka->sa.sa_flags & SA_SIGINFO)
  setup_rt_frame(sig, ka, info, oldset, regs);
else
  setup_frame(sig, ka, oldset, regs);
//here ， 我加了debug信息， 确实执行到这里了，
if (ka->sa.sa_flags & SA_ONESHOT){  //sys_signal()函数明明设置了这个标志
  //通过debug ，知道居然没有到这里，就说明， sa_flags 根本就没有SA_ONESHOT标志了 ，可是sys_signal() 却又明明设置了这个标志， 而且我搜索过， 根本没有地方，取消了 SA_ONESHOT 标志
  printk(" the signal (%d) handler will reset to SIG_DFL＼n",sig);
  ka->sa.sa_handler = SIG_DFL;  //这难道还不明确吗？
if (!(ka->sa.sa_flags & SA_NODEFER)) {
  spin_lock_irq(¤t->sigmask_lock);
  sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
  sigaddset(¤t->blocked,sig);
  recalc_sigpending(current);
  spin_unlock_irq(¤t->sigmask_lock);
}
}
既然这样的话  ，如果我们调用signal（）就应该在信号处理函数中反复注册自己的信号处理函数才对 ， 否则无法处理下一个同样的信号了。
比如 void signal_catch(int signo)
{
//信号处理函数细节
//最后一行
signal(signo, signal_catch); //再注册一遍， 否则就变成  SIG_DFL 了 。
}
对于这个问题 《Unix Advanced Programming》 也提到过，说早期的Unix 也存在这个问题， 是信号不可靠的一个原因 （见 P206）
不过实际上我们在用signal()函数的时候 ， 我们似乎并不必这么作  ，比如一个简单的测试程式。
为了测试， 我写了一个最简单的例子：
void sigterm_handler(int signo)
{
          printf("Have caught sig N.O. %d＼n",signo);
          //按照kernel代码，应该还要有signal(signo,sigterm_handler);   才对呀 ，但事实上，我们大家都知道没有必要这样用 ，为什么呢？ 请前往论坛讨论：
http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxK&Number=607961&page=0&view=collapsed&sb=5&o=7&fpart=&vc=1&PHPSESSID
=
}
int main(void)
{
       printf("-------------111111111111111-------------＼n");
        signal（SIGTERM,sigterm_handler);
     pause();
       printf("----------222222222222222----------------＼n");
      
        pause();//如果按照kernel代码里面写的， 当再发一个SIGTERM信号的时候 ， sa_handler 就编程SIG_DFL 了，那默认就是 //terminate ，所以不会打出来 333333333333333333  了，  
       printf("-------------3333333333333333----------＼n");
      
        return 0;
}
不过执行结果确实：  
333333333333333333333333 也打出来了， 这就又说明signal函数 ，不必反复注册信号处理函数 ，  这不就矛盾吗？  
所以目前问题就是
if (ka->sa.sa_flags & SA_ONESHOT){  
  ka->sa.sa_handler = SIG_DFL;
是在什么情况下 改动了 sigaction->sa_flags (去掉了 SA_ONESHOT 标志呢？)我在代码里面搜索不到啊！
如果感兴趣的朋友能前往论坛讨论：
http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxK&Number=607949&page=0&view=collapsed&sb=5&o=7&fpart=&vc=1

2> 僵尸进程：也叫Zombie进程：  
僵尸进程定义：进程结束后，该进程的父进程没有调用wait或waitpid（）对子进程进行回收 ， 子进程一直是Zombie状态。
关于kernel怎么杀死Zombie 请看 kernel/exit.c ==>sys_wait4() 函数 ， waitpid 就是sys_wait4()实现的。

首先看看正确的编程方法：
当一个进程fork（）出一个子进程的时候 ，正确的情况下，父进程应该回收进程的资源：通过下面两个办法中的一个即可避免Zombie（僵尸进程）：
 父进程显式的忽略SIGCHLD 信号
只要在fork一个子进程之前加上这么 一行：   signal(SIGCHLD, SIG_IGN);  //这样肯定不会出现僵尸进程，
为什么呢？  看kernel的代码吧：
==>asm/i386/signal.c  ==>do_signal()
  ka = ¤t->sig->action[signr-1];//¤t->sig : signal_struct
  if (ka->sa.sa_handler == SIG_IGN) {
   if (signr != SIGCHLD)
    continue;  //对于信号处理方式是 SIG_IGN ， 非SIGCHLD的信号 ,kernel什么也不作！ SIGCHLD 比较特别啊！
   /* Check for SIGCHLD: it’s special.  
    类似调用waitpid（）来回收child process的进程表项
   */
  //SIG_CHLD 信号的行为设置为SIG_IGN  , 由内核来处理僵死进程。
  //如果你的程式中没有特别的需求需要处理SIGCHLD , 为了避免僵尸进程（Zombie进程），你能显式的忽略他，kernel会调用sys_wait4（）来处理僵尸进程的），他执行一个while() loop , 来处理系统中所有的僵尸进程，老黄牛精神啊！   
   while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)   // 看看是不是和waitpid的用法相同啊！  
    /* nothing */;
   continue;
  }
如果 SIGCHLD 是默认的  SIG_DFL 的话：kernel就不管了，所以肯定会有僵尸进程的！
==>asm/i386/signal.c  ==>do_signal()
  if (ka->sa.sa_handler == SIG_DFL) {
   int exit_code = signr;
   /* Init gets no signals it doesn’t want.  */
   if (current->pid == 1)  //谁都不能给init(1) 进程发信号， 这样说比较准确： 发了也白发，kernel不认可
    continue;
   switch (signr) {
   case SIGCONT: case SIGCHLD: case SIGWINCH: case SIGURG:
    continue;  //对于SIGCHLD 信号，kernel对他默认是忽略的， （请不要和SIG_IGN 混淆了）
      //所以非常明显， kernel并没有调用sys_wait4() 来处理僵尸进程 ，你要自己处理了，^_^
  ..............
  }
 父进程给SIGCHLD信号注册handler（里面调用waitpid（）回收child Zombie process)
比如：这样写：
while(waitpid(-1,NULL,WNOHANG) > 0)  {   //自动处理所有的僵尸进程，当然你能不用while，只调用一次，看需要 ： 比如父进程是个http server，就会fork（）出非常多子进程 ， 所以while()是有必要的。
//WNOHANG 非常关键，如果没有僵死进程，就马上返回 ，这样while（）才能结束啊 ， 可是wait（）就没有这个参数，  所以wait就阻塞了。 所以一般情况下，我们用waitpid还是最佳的了！
;//什么也不必作了， 能打印看看到底回收了哪些进程pid
}
！如果你没有用上面所有一个办法,就会出现僵尸进程。  
ps ax 命令可能会显示：  
22149 tty8  S  0：00   test_pro
22150  ?    Z  0:00    [test_pro ]   //这就是僵尸进程  Z 就是Zombie的意思 ， 你用kill -9 也无法杀掉他 。
怎么杀掉Zombie进程呢？  你能kill他的父进程就能杀掉Zombie进程。
kill -SIGTERM 22149 ,  你在ps ax 看看  ，两个进程都没有了。

避免僵尸进程的第三种办法
个人不推荐！ 因为上面两种方法已够用了， 除非你更有其他的需求，比如 使子进程无法获得控制终端，这种情况下， 就必须fork()两次了 。 否则一般情况下，我们需要父子进程同步和通信的， 父亲和儿子交流尚且比较方便（用pipe最佳，配合使用select（）） ， 你让爷爷和孙子通信不是比较困难吗？  两代人的代沟呢。。。。
当       你也能fork()两次，  父亲(比如http server，循环处理） ->  儿子进程（exit） -> 孙子进程 （处理每次的任务，正常结束，就不会成为Zombie）  

下面是事例代码：   
pid_t pid = 0;
pid = fork();
if(pid  0)
//这里可能是个Server一类的， 父亲进程永远不会结束的，是while（） 循环
else {
//目前儿子 process 了，
if(pid = fork()  0) //儿进程也结束了
  exit(0);//即时杀死儿子进程 ，这样孙子就成孤儿了，孙子进程会被init（1）领养的。
else { //到孙子进程了。
  /*  some code …………..
  */
  exit(0);
   }
}
对于 原理其实非常简单： 儿子死了， 只有孙子了， 孙子是孤儿了， 那么init(1)进程就会领养这个 孤儿，  同时孤儿就认为init(1)就是他的父进程，由init进程负责收尸！   
3> 特别的 SIGCHLD 信号
SIGCHLD 特别在哪里呢？？ 一般情况下， 子进程结束后 ，都会给父进程发送 SIGCHLD 信号 ，不过这不是绝对的 。
• 当一个父进程fork（）一个子进程后，  当父进程没有为SIGCHLD 注册新的处理函数，处理方式为SIG_DFL  ,那么当子进程结束的时候， 就不会给父进程发送SIGCHLD 信号 。
   从代码的角度： 执行到send_sig_info()，会在isgnore_signal() 函数里面做是否要发信号的判断，结果 SIGCHLD被忽略了！

• 就是普通的进程，在某个地方pause()，也不是随便发一个信号就能唤醒他， 比如 发 SIGCONT 信号(在kernel中当SIGCONT 的处理方式为SIG_DFL的时候， 他要被ignore的) ，就不能！
例子：  int main(void)
{
  pause();
  printf(“I am waken up＼n”);
  return 0;
}
如果你在外部随便发下列信号：SIGCONT , SIGWINCH , SIGCHLD SIGURG ，肯定是要被进程忽略的，并不能唤醒该进程！  
如果你发SIGTERM,SIGQUIT,SIGINT等信号，没有注册handler ， 那么默认是中止他；如果注册了handler ， 则能唤醒该进程。
且看下面的代码分析：
/*
* Determine whether a signal should be posted or not.
*
* Signals with SIG_IGN can be ignored, except for the
* special case of a SIGCHLD.
*
* Some signals with SIG_DFL default to a non-action.
*/
//定义了那些信号要被忽略!

static int ignored_signal(int sig, struct task_struct *t)
{
/* Don’t ignore traced or blocked signals */
if ((t->ptrace & PT_PTRACED) || sigismember(&t->blocked, sig))
  return 0;
return signal_type(sig, t->sig) == 0;  
}
/*
* Signal type:
*     0 : wake up.
*/
//
#define SIG_DFL ((__sighandler_t)0) /* default signal handling */
#define SIG_IGN ((__sighandler_t)1) /* ignore signal */
#define SIG_ERR ((__sighandler_t)-1) /* error return from signal */
//
static signal_type(int sig, struct signal_struct *signals)
{
unsigned long handler;
//-----------------------------空信号 ignore  -----------------------------
if (!signals)
  return 0;   //

handler = (unsigned long) signals->action[sig-1].sa.sa_handler;
if (handler > 1)   //该信号有特定的信号处理函数不能ignore ，必须wake_up ()
  return 1; //can’t ignore
// -----父进程设置SIGCHLD 的处理方式为 SIG_IGN : 子进程结束的时候不会给父进程发信号，也就无法唤醒了。
/* "Ignore" handler.. Illogical, but that has an implicit handler for SIGCHLD */
if (handler == 1)   
  return sig == SIGCHLD;//当信号是 SIGCHLD的时候，信号不能被忽略，其他的要被活略
// --------------------------当把信号设置为SIG_DFL 时的情况---------------------
/* Default handler. Normally lethal, but.. */
switch (sig) {
/* Ignored */
case SIGCONT: case SIGWINCH:
case SIGCHLD: case SIGURG:
  return 0; //这些信号忽略干脆就忽略了 ，那你可能奇怪了？那SIGCONT 信号怎么唤醒 TASK_STOPPED状态的进程呢？  如果你有这个疑问 ，请看 5>的讨论！
/* Implicit behaviour */    //can’t ignore
case SIGTSTP: case SIGTTIN: case SIGTTOU: //这些信号就时要暂停进程的
  return 1; //这些信号会唤醒该进程的， 程式会接着望下跑的，  最后 把进程的状态置为 TASK_STOPPED 的。
/* Implicit actions (kill or do special stuff) */
default:  //对于象SIGKILL , SIGTERM ,SIGQUIT 这样的信号直接就默认操作， 一般就是terminate 该进程
  return -1;
}
？怎么在应用程式验证上述kernel的代码呢？
既然提到了”唤醒“ ，肯定要用上  pause(2)函数了， 且看pause（2）的manunal ：
DESCRIPTION
       The  pause  library function causes the invoking process (or thread) to
       sleep until a signal is received that either terminates it or causes it
       to call a signal-catching function.  （也就是发的信号有对应的信号处理函数，或是强行中止的哪些信号）
RETURN VALUE
       The  pause  function only returns when a signal was caught and the sig-
       nal-catching function returned. In this  case  pause  returns  -1,  and
       errno is set to EINTR.
上面的手册说得非常清晰了， 对于pause过的进程，  只有发送类似 SIGKILL , SIGQUIT, SIGTERM 的信号或是 注册了新的处理函数，才能唤醒他！
另外再看一下：pause()的系统实现：
asmlinkage int sys_pause(void)
{
current->state = TASK_INTERRUPTIBLE;  //设置成INTERRUPTABLE 状态，就不在CPU调度的队列里面了
schedule();//重新调度，使当前进程即时让出CPU，  kernel从TASK_RUNNING队列中选择合适的进程重新运行
return -ERESTARTNOHAND;
}
下面是测试的例子：  
#include
#include
#include
#include
#include
#include
#include
void sig_handler(int signo)
{
        printf("signo = %d＼n",signo);
        if(signo == SIGCHLD) {
                pid_t child_pid = 0;
                int status = 0;
                printf("into singal handler＼n");
                //wait() fault : it will blocked if no defunced  process ,so I will use waitpid(.. WNOHANG) ,it will return immidietly
              while( (child_pid = waitpid(-1,&status,WNOHANG))> 0) //循环回收所有的Zombie进程
                      printf("child_pid = %d  ,  status = %d＼n",child_pid,status);
        }
}
int main(void)
{
        pid_t pid = 0;
/* 感兴趣的读者能试试！你能试着注释掉下面的两个signal()函数， 用这个，试着回答下面的两个问题
        struct sigaction sa,old_sa;
        sigaction(SIGCHLD,&sa,&old_sa);
        sa = old_sa;
        sa.sa_flags |= SA_NOCLDSTOP; //当子进程结束的时候，阻止子进程向其父进程发SIGCHLD
        sa.sa_handler = SIG_IGN;
        sigaction(SIGCHLD,&sa,NULL);
*/

  signal(SIGCHLD,sig_handler);  //避免僵尸进程
  //signal(SIGCHLD,SIG_IGN);   //注释上面那行，用这行 ， 再试着重新回答下面的两个问题
  pid = fork();
        if(pid
                printf("child ................... ＼n");
                exit(0);
        }
        else {
                printf("parent pause() ..............＼n");
                pause();   //父进程会被唤醒吗？？？？？？？？？？？？？？？？？？？
                fflush(stdout);
                printf("parent process has been waken up ＼n");
                return 0;
        }
}
大家能思考一下？
（1）  子进程会成为孤儿进程吗？     
（2）  父进程会被唤醒吗？
如果你看明白了上面的kernel代码 ，你就非常快明白了答案了：（上面没有被注释的代码的运行结果 ，注释的部分，读者自己能验证试着读原始码解释程式行为！
（1）答：不会，正常结束 ，因为有声明 ：signal(SIGCHLD,SIG_IGN);   //避免僵尸进程
（2）答：（至少在linux-2.4.24上会，我在linux-2.4.20-8上试了一下，就不会唤醒,代码肯定不同了）， 因为子进程结束后， 会给parent进程发送一个SIGCHLD 信号， 此信号会唤醒 parent 进程！ 有关这方面的讨论能访问论坛页：
http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxK&Number=607949&page=0&view=collapsed&sb=5&o=7&fpart=&vc=1

  
4> 在给一个进程发送信号的过程中， 只要目标进程（迟早要成为当前running的进程）没有block该信号， kernel都会调用 wake_up_process（） 函数来唤醒他 ， 为什么呢？   因为 只有当前活动进程才会handle signal ，过程是这样的：  当一个进程被唤醒后， 他肯定处于kernel空间 ， 在他即将返回道用户空间的时候， 开始检测 task_struct->sigpending ,如果为1   就说明该进程收到了信号（目前这个信号叫pending信号，只要有pending 信号， sigpending 就是等于1 ） ，开始调用do_signal() 函数来处理 ， 也就是重要的一点 ， 只有当前活动进程才能处理信号（类似中断 ， 当一个进程收到一个信号后， 就active了， 至于该信号怎么处理，是 "kernel处理信号的任务“ 。
具体说明如下：
关于这个函数我觉得也也值得注意！
1> 当向一个进程发送 SIGCONT信号时候，
如果进程本身更有一些类似SIGSTOP,SIGTSTP,SIGTTIN,SIGTTOU等会使进程停止的信号，
就要把他们删掉
2>如果想要停止某个进程的话，
就一定要删除SIGCONT信号（这个肯定，否则kernel在处理的时候，
进程优先处理SIGCONT信号，然后再处理这4个 ，那就多余了，没有必要。既然要停止，
就直接停止，忽略之前的SIGCONT操作）
static void handle_stop_signal(int sig, struct task_struct *t)
{
switch (sig) {
case SIGKILL: case SIGCONT:
  /* Wake up the process if stopped.  */
  if (t->state == TASK_STOPPED)
   wake_up_process(t);
  t->exit_code = 0;
  rm_sig_from_queue(SIGSTOP, t); //删除这些未决信号
  rm_sig_from_queue(SIGTSTP, t);
  rm_sig_from_queue(SIGTTOU, t);
  rm_sig_from_queue(SIGTTIN, t);
  break;
case SIGSTOP: case SIGTSTP://因为这些信号排在SIGCONT信号的后面，如果不删除队列中的SIGCONT信号， 在do_singal()会先执行SIGCONT的操作的，这样就多次一举了。Note：我看代码里面是 kernel在检测信号的时候， 先处理sigset_t类型值中前面的bit对应的信号
case SIGTTIN: case SIGTTOU:
  /* If we’re stopping again, cancel SIGCONT */
  rm_sig_from_queue(SIGCONT, t);
  break;
}
}
  
5> ？ 对于3>提到的特别的SIGCHLD 信号， 我们提到了到底哪些信号要被忽略。那么对于善于思考你， 不知道你是否有此疑问：
  （1）对于一个普通的进程发SIGCONT 信号肯定是要被kernel忽略的；
  （2）不过一般的上层熟悉signal用法的R&D都知道 SIGCONT信号是SIGSTOP/SIGTSTP/SIGTTIN/SIGTTOU的后继信号， 是专门用来把挂起的进程恢复running的，根据上面的结论SIGCONT不是也要被忽略的吗？？？？ 那进程又怎么可能恢复执行呢？
  
答案：要回答这个问题就要弄清晰kernel在发一个signal的流程：  
1. 判断信号是否是bad的，  参考 kernel/signal.c ==>bad_signal()
2. 处理状态是TASK_STOPPED的进程， 如果是 ， 就调用wake_up_process() , 参考 kernel/signal.c==>handle_stop_signal() 函数
3. 判断哪些信号该忽略，参考 kernel/signal.c==>ignore_signal()
4. 最后 调用 deliver_signal（） 正是发送信号（其实发送信号，说白了，就是修改task_struct 相应的数据成员），发送完信号成功后，如果进程是处于TASK_INTERRUPTABLE 状态的（且信号没有被阻塞）， 就唤醒他。
到此为止，信号就算正式发送完毕了。
所以，你目前你就知道答案了：
虽然SIGCONT 信号要在 3.被忽略，可是2. 却能被执行， 进程被变为TASK_RUNNING 状态了（！TASK_RUNNING状态的进程有非常多，不过同一个时间，占用CPU的就只有一个）
那为什么要必须把 TASK_STOPPED 状态的进程 变为 TASK_RUNNING 呢？  也许你能从 4>中得到答案！
6> ！关于阻塞信号注意事项
1. 阻塞信号非常有用， 比如你运行某个程式， 比如upgrade 程式， 再比如更新BIOS ， 都是不允许忽然断电和忽然停止的，否则会发生灾难性的后果！至少在代码某个部分，是不能停止的，这个时候 必须阻塞一些信号（比如SIGTERM,SIGQUIT,SIGINT等等）。阻塞信号后， 在适当的时机要对该信号解除阻塞！以处理被阻塞信号！
利用信号阻塞能实现上面的功能，你能在关键的不可停止的代码上面加 sigprocmask（&block_set）函数阻塞一个信号集，这样当这部分关键代码执行的时候，阻塞block_set集合里面的信号， 这些信号只有被解除阻塞的时候，才能被处理！ 当关键代码执行完毕后， 你再 调用suspend(&zero_set) 来允许所有的信号， 为的就是处理刚才被阻塞的信号，比如如果刚才发了SIGQUIT信号，目前就能处理SIGQUIT信号了，最后（如果你的程式还没有中止，要继续执行其他操作的话）调用sigprocmask(SIG_SETMASK,&old_set,NULL); 来恢复原来的信号掩码集合，使你的程式继续running下去！
下面是例子程式：例子程式我写了周详的操作说明，读者能清晰了解sigsuspend()的用法
程式说明： 在执行critical code的过程中，不允许SIGQUIT信号，你能随意copy使用！
#include
#include
#include
void sig_int(int signo)
{ printf("int:signo %d＼n",signo);
}
void sig_quit(int signo)
{ printf("quit:signo %d＼n",signo);
}
int main(void)
{
sigset_t newmask,oldmask,zeromask;
signal(SIGINT,sig_int);  //only test
signal(SIGQUIT,sig_quit);//only test
sigemptyset(&zeromask);

sigemptyset(&newmask);
sigaddset(&newmask,SIGQUIT);
printf("just sigprocmask , blocked newmask ＼n");
sigprocmask(SIG_BLOCK,&newmask,&oldmask );

/*critical code begin */
printf("only testing ,please send SIGQUIT signal to test,it will be blocked ＼n");
pause();//在这里停住仅仅用于测试， 否则程式马上掠过这里， 你将没有机会测试 SIGQUIT信号了！
//实际使用的时候，你不能用pause()
/*critical code over */
//deal these blocked signal
printf("allow all signals, and deal all blocked signals ＼n");
sigsuspend(&zeromask);
printf("haha , SIGQUIT has been deal ＼n");
printf("will restore the signal mask ＼n");
sigprocmask(SIG_SETMASK,&oldmask,NULL);
printf("has restored ,please testing with SIGQUIT ＼n");//这个时候，没有阻塞SIGQUIT信号！
pause();   //这里也仅仅用于测试 ，你能发SIGQUIT信号试试！
printf("haha , testing over ,this is suspend () usage ＼n");
exit(0);
}
上面演示了sigsuspend（）和sigprocmask的用法， 通常情况下，这两个函数都是配合使用的，其他的例子能参考《Unix Advanced Programming 》P229
2．？如果我阻塞了一个信号， 不过当我恢复信号阻塞掩码的时候， 我并不想处理该信号我该怎么办呢？比如SIGQUIT信号，如果我不另加处理， 他会中止程式的，天哪？那怎么行？
这个时候需要用到sigpending()这个函数了， 当你的关键的code 段，结束后， 你能利用sigpending()来检查某个信号是否在pending中，然后设置这个信号的处理方式， 比如，如果你想删除这个信号， 直接忽略他 。 等恢复了原来的信号阻塞掩码后，再恢复该信号的处理方式！
还是据个例子吧：
#include
#include
#include
int main(void)
{
sigset_t block_set,save_set;
sigset_t pending_set;

sigemptyset(&pending_set);

sigemptyset(&block_set);
sigaddset(&block_set,SIGQUIT);
sigprocmask(SIG_BLOCK,&block_set,&save_set);

/* your key code segment ,can’t be interrupt by SIGQUIT
   code
  */
  printf("Please send SIGQUIT signal , by  Ctrl+ ＼＼ ＼n");
  sleep(6);  //仅仅是为了测试，这个时候 ，你能发SIGQUIT信号,实际应用中，这个肯定不要的！
printf("key code has been end !＼n");
printf("you can unblock those signals＼n");
  //如果你发了SIGQUIT 信号， 这时候， 肯定在pending里面了
  
  sigpending(&pending_set);
  if(sigismember(&pending_set,SIGQUIT)) //测试SIGQUIT是否在pending队列中
  { printf("yes , SIGQUIT is pending signal＼n");
   signal(SIGQUIT,SIG_IGN);  //暂时改动一下SIGQUIT的行为，稍后再改回去！
  }
// sigsuspend(&zero_set);  //来处理其他的刚才被阻塞的信号，不过不处理SIGQUIT信号
  sigprocmask(SIG_SETMASK,&save_set,NULL);
  signal(SIGQUIT,SIG_DFL);  //复原SIGQUIT的信号部署方式
  printf("yet pause() , please ctrl+＼＼ to test SIGQUIT’s handler ＼n");
  pause(); //仅仅测试，SIGQUIT 是否还被阻塞
  
  return 0;
  
}

3．另外两个比较有用的函数：sigwaitinfo(), sigtimedwait(),   专门等待某种信号的到来，sigtimedwait()能在有限的时间内等待某个信号集！而且sigwaitinfo() | sigtimedwait()也是经常和sigprocmask配合使用， 当然只用sigwaitinfo()系列也能！而且功能也相同！为什么这样？请man 2 sigwaitinfo，你一定能找到答案！，不过如果配合sigprocmask功能会更多一些！比如你想要哪些信号到来（sigwaitinfo（）），但又不想要哪些信号（sigpromask）
具体的复杂的可应用的例子能参考8>中的父子进程通信的例子。
使用注意事项：
sigwaitinfo(wait_set)等待set信号集中的信号的到来， 如果在没有等到信号集中的信号，或收到了一个不在set集合中的信号，该函数就会返回-1,在返回-1之前会处理这个不速之客（或默认处理，或调用信号处理函数）。
这里举个简单的例子；也加进了sigsuspend（）函数，来处理增经阻塞过的信号
请注意block_set和wait_set的差别
#include
#include
#include
/*
* 该程式主要是说明并演示 sigwaitinfo（）和sigsuspend（）和sigprocmask（）的用法
* 用法和说明
  sigwaitinfo仅仅等待set里面的信号， 当收到这个信号后， 仅仅返回signal值和信号的信息siginfo_t, 不执行信号处理函数（如果注册了信号处理函数的话）
  sigsuspend()相当于 先sigprocmask() ,然后再pause() , 不过sigsupend（）是个原子操作
• 程式功能：
程式运行过程中wait SIGINT信号， 在调用sigwaitinfo之前阻塞了 SIGINT 和SIGQUIT信号，
如果sigwaitinfo（）阻塞的时候， 发SIGQUIT信号，必然要被阻塞， 程式依旧睡眠， 当发送SIGINT信号的时候， 也要被阻塞， 不过sigwaitinfo一旦检测到pending 信号中有SIGINT，就即时返回 。
程式继续执行， 不过我们要处理刚才发送的被阻塞的SIGQUIT信号， 所以调用suspend（&zero_set）来处理所有被阻塞的信号 ， 所以调用SIGQUIT的信号处理函数， 然后从suspend（）返回， 程式继续执行！调用sigprocmask（）来恢复原来的信号掩码集。
           --bob
*/
void sig_quit(int signo)
{
printf("======================SIGQUIT=======================＼n");
}
int main(void)
{
sigset_t wait_set,block_set,old_set,zero_set;
siginfo_t info;
int recv_signo = 0;
signal(SIGQUIT,sig_quit); //你能捕捉SIGQUIT信号，随你的便，如果你不想被SIGQUIT退出的话。
sigemptyset(&zero_set);
sigemptyset(&wait_set);
sigaddset(&wait_set,SIGINT);


block_set = wait_set;
sigaddset(&block_set,SIGQUIT);  //阻塞了block_set集合里面的信号， 比wait_set多阻塞了一个SIGQUIT信号！，读者能在这里加上你想阻塞的信号，这些信号可能会对正常的流程不利！

sigprocmask(SIG_BLOCK,&block_set,&old_set);
recv_signo = sigwaitinfo(&wait_set,&info);
printf("--debug recv signo = %d＼n",info.si_signo);
printf(“recv signo = %d＼n”,recv_signo);  //确实收到了想要的信号时，结果和上面相同， 收到了 wait_set意外的信号时， 就返回 －1  ，所以用这个判断是否出错，比较好！
/*----this is error ,为什么错，please see 《unix advanced programming》P229－230 */
//sigprocmask(SIG_SETMASK,&old_set,NULL);//restore the signal mask
//pause();
/* ----------------------------------------------------------------------------*/
sigsuspend(&zero_set);//临时允许所有的信号，为的处理刚才有可能被阻塞的信号！

/* ---------------目前信号掩码集合已被恢复设置了， 你能再试试 SIGQUIT 信号了。这个时候就能处理 SIGQUIT信号了。
* ---------------虽然下面两行看起来和上面注释的认为的错误行相同，可是他的用途确实孑然不同 ，你看出来了吗？
*/
sigprocmask(SIG_SETMASK,&old_set,NULL);//restore the signal mask
pause();

return 0;
}
？对于上面的程式读者不知道发现一个bug没有？  就是如果这个时候在等SIGINT的时候， 发生了别的信号比如SIGQUIT,SIGTERM什么的，程式该怎么运行呢？  答案： 不妙， 本来时要等待SIGINT 信号的，不过没有等到，由于收到其他的信号可能会异常退出， 这怎么能行呢？ 所以当收到了其他的信号的时候， 一定要判断errno == EINTR
改进如下：
……………………………………………………………..
again:
sigprocmask(SIG_BLOCK,&block_set,&old_set);
recv_signo = sigwaitinfo(&wait_set,&info);

If(recv_signo == -1) {  //那就出错了，不过 -1 ，包含了两种情况 EINTR 和 EAGAIN
  If(errno == EINTR)  //表示被别的信号给中断了
  {
   goto again;  //重新调用sigwaitinfo() 继续等待
  else if(errno == EAGAIN);   //如果你用的时sigtimedwait()函数，这个也许有用，表示在规定的timeout时间无法获得资源，  errno== EAGAIN
   ;  //do nothing ，直接退出即可（当你用sigtimedwait()的时候）
}
else {  //收到我们想要的信号
  printf("--debug recv signo = %d＼n",info.si_signo);
  printf(“recv signo = %d＼n”,recv_signo);  //确实收到了想要的信号时，结果和上面相同， 收到了 wait_set意外的信号时， 就返回 －1  ，所以用这个判断是否出错，比较好！
}
！我们通过一个循环来判断该sigwaitinfo（）系统调用是否是被信号中断的， 如果是就继续循环重新调用sigwaitinfo（）来阻塞并等待期待的信号的到来！

7>！不可再入函数
比如malloc（）， printf（）， 这些都是不可再入的函数！，使用不可再入的函数使危险的，不要用他们， 具体哪些是不可再入的，哪些使可再入的， 要查看《unix advanced programming》P209
这里指出最常见的错误：
在信号处理函数中：
• 不能调用malloc（）函数来动态分配内存，因为主程式在被信号中断的时候， 有可能正在调用malloc（）函数，也就是主程式调用malloc的时候被中断了。
• 不能调用printf（）来打印信息！当然偶尔调试也问题不大， 不过调试成功后， 要去掉printf()函数！
8> 关于信号的技巧：
 Q ：怎么判断一个进程是否还活着 ？
A： 发一个空信号就好了， 什么？什么是空信号？  就是  0
 Q：怎么暂时挂起某个进程？
  A: 如果你想暂时挂起某个进程的运行，以后要恢复，请用SIGSTOP信号 ， 想重新执行该进程的时候，就发SIGCONT信号。 记住当你对一个进程发SIGSTOP信号的时候，  子进程会给父进程发SIGCHLD 信号，这样父进程会被唤醒。具体为什么请看 3> ，kernel 代码里面已非常清晰了。
 Q：我想父子进程间通信而且同步，比如： 父进程需要等待子进程执行的结果，然后最会退出， 当然不能无限期等待，比如等 5秒钟 ， 用信号行吗？  
A：你以为信号是万能的？ 不过这个功能用信号确实能实现，而且还非常简单。
具体的我们来分析一下：
1. 同步：这是信号的最基本的功能了， 无论你用signal()/kill() 系列还是  sigaction()/sigqueue() 系列肯定能满足你的需求 。
2. 通信：如果你用kill(2)函数发信号， 通信肯定不可能了， 传递不了信息啊，接收进程只知道收到收到这个信号，不过到底发生了什么事情一概不知！这也是kill(2)的局限了！
   你能用sigqueue（）函数 ，里面有项参数就是用来传递数据的 ，内核里面有个结构叫 siginfo_t ，就是干这个用的。具体请看
http://www-128.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html
（进程间通信 信号（下），里面举了个例子）
3. 父进程有限时间等待子进程，用sigtimedwait（const sigset_t, siginfo_t *info, const struct timespec timeout） ，不过仅限于等信号，可不是等别的什么！
举个非常有实用价值的例子：比如有个downloader （libcurl），我想在主程式中调用curl执行下载， 然后主程式等待curl的下载结果，能只等5秒钟， 如果5秒钟还是没有收到信号， 说明curl一直在执行！
主进程fork（）出一个子进程 ，子进程去作真正的事情。
为了方便理解，用子进程运行curl下载文件 ，根据文件的大小和网速，下载时间会有非常大不同。
下面分三种情况：
 file比较小， 子进程（curl进程）非常快返回，下载完毕
 file比较大， 子进程（curl进程）过20分钟返回，下载才完毕。父进程刚开始timeout时间就结束了。
 URL出错， 子进程马上返回一个出错码！
父进程能根据这三种情况update某个 database，来记录这次的下载状态！并及时的反馈给前端的UI
下面是我写的程式， 非常高兴被你随意copy！
思路1： 用signal来实现， 非常简单和直观！（对比下面的pipe做法）
父进程需要在有限的时间内等待子进程发送SIGUSR2信号， 而子进程结束时候，也要报告自己的exit code ，不过这个时候父进程已结束了，子进程被init（1）领养 ，所以就不用报告状态了，直接被init(1)回收！
下面是代码：
#include
#include
#include
void sig_usr2(int signo,siginfo_t *info,void *myact)
{
printf("signo = %d＼n",signo);
}
int main(void)
{
sigset_t wait_set;
int sig_no;
const struct timespec tv = {5,0}; //timeout
siginfo_t sig_info ;//传递的信息结构
pid_t pid = 0;
sigemptyset(&wait_set);
sigaddset(&wait_set,SIGUSR2);

signal(SIGCHLD,SIG_IGN); //父进程显式的忽略子进程发来的SIGCHLD信号 ，防止出现Zombie 进程，如果忘记了，复习一下上面！
pid = fork();
if(pid
http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.24.tar.gz
&>/dev/null");
  printf("rc = %d＼n",rc);
  rc_val.sival_int = rc/255;  //传递整型值
  if(getppid() > 1) { //因为如果过了timeout ， 父进程就退出了， 该子进程被init(1)领养， 所以千万不要向init(1)发信号！否则整个系统都要reboot 了！
   sigqueue(getppid(),SIGUSR2,rc_val);//给父进程发信号！，getppid()能获得父进程的pid
  }  
  exit(0);
}
  
//parent process
sigprocmask(&wait_set);
sig_no = sigtimedwait(&wait_set,&sig_info,&tv); //父进程会一直阻塞tv时间，然后就返回
if(sig_no == -1) {   //说明超时
  printf("child process timeout ＼n");
  printf(“curl 一直没有返回，这样下载看起来没有问题， 正在下载＼n”);
}
else {
  printf("child process return value = %d＼n",sig_info.si_int);
  if(sig_info.si_int == 0)   //信号传递的信息！ 我们在这里传递integer值！
   printf(“下载完毕＼n”);
  else
   printf(“下载出错，错误代码 %d＼n”, sig_info.si_int);
}
return 0;
}

为了比较， 我原来写过一个用 无名管道/select 来实现 上述功能的， 不过你需要了解pipe和select的用法，需要的知识点比较多。
你能随意copy我的代码，
思路2：用pipe实现父子进程通信，再配合select()在timeout时间内监视管道读管道）
父进程创建了一个无名管道， 子进程在管道写端写入value ， 父进程通过select（）函数检测管道的读端，如果5秒钟内读端无反应，说明超时，否则就能读value！ 这样就是简单的实现父子进程同步，通信，且有限时间等待的需求！
pid_t pid = 0;
int fd[2];    //pipe operation :
unsigned char share_buffer[3]; //share info between parent process and child process
  
fd_set read_fds;
int fd_max ;     /* for select */
struct timeval tv;
int select_rc = 0;
if(pipe(fd)
  setsid();
  /* generate a daemon process
    * setsid()是创建daemon的关键函数，（1）成为session的leader process ，
    *（2）成为进程组的leader process ，（3）没有终端
    */
   umask(0);
   /* 当创建文件的时候和目录的时候 默认是 umask(022) ，
    * umask（）函数能改便创建文件时候的默认许可权位 ， 据个例子，当你用root权限
    * 创建一个文件 ， > bob.txt   ,你会发现： ll bob.txt ,  显示 -rw-r--r-- ，
    * 这就是umask(022)的作用 ， 022 对应的二进制： 000     010 010 ，表示 对于
    * 组内用户和其他的用户 不可有w的权限。   w位置1 就表示不能w ！以此类推！
   close(0);   //关闭标准输入
  close(1); //关闭标准输出
  close(2); //关闭标准错误输出
  chdir(“/”);
  close(fd[0]); //把管道的读 一端 关闭 ，只留写 一端 即可
//执行你的程式 ，你的code
。。。
//在exit（0）之前，通知你的父进程你的执行结果， rc就是执行结果
buffer[0] = rc;
buffer[1] = ’＼0’;
buffer[2] = ’＼0’;
write(fd[1],buffer,sizeof(buffer));
close(fd[1]); //end of write to the "write pipe" ,must close it
exit(0);
}  //子进程结束！
//父进程内
close(fd[1]); //关闭写端 ，只要留着读端即可！
  
FD_ZERO(&read_fds); //clear the read_fds
        FD_SET(fd[0], &read_fds);
        
        tv.tv_sec = 5  //假设父进程就等待5s
        fd_max = fd[0]+1;
               
        //select 不熟悉select()的朋友能到google搜索他的用法，一定要掌控！
        select_rc = select(fd_max,&read_fds,NULL,NULL,&tv);

if(!select_rc) //wait超时 ，
  //你的处理code ， 也许这正是你期待的呢！
else {
  read(fd[0],share_buffer,sizeof(share_buffer));
  jprintf("read successfully＼n");
  jprintf("in father :buffer[0] = %d＼n",share_buffer[0]);
  jprintf("in father :buffer[1] = %d＼n",share_buffer[1]);
  jprintf("in father :buffer[2] = %d＼n",share_buffer[2]);
  close(fd[0]); //close read pipe , 读完毕后记着关闭他！
  //你能根据buffer读出的内容作进一步的处理
  //你的code
}
………………………………..
附录：
参考资料：
1. 《linux内核原始码情景分析》上册 ，对kernel代码分析的周详完全，不回避难点，非常多kernel代码分析的书没有讲到的知识，他基本上都讲到了，而且周详透彻，值得一读！
2. 《深入理解linux 内核》，虽然没有《情景分析》那么详尽细节， 不过总是有画龙点睛之笔，让人惊叹作者的功力之深看问题的锐利！建议先看他，看代码的时候，再看情景分析！
3. 《Unix环境高级编程》，是每个linux编程者必备的手册。
4. 进程间通信 信号（上）
http://www-128.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html
绝对的好文章
5. 进程间通信 信号（下）
http://www-128.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html
同一个人写的
6. signal(),signaction(),sigwaitinfo(),sigtimedwait()等其他函数的manual
文件完
作者：英文名bob  ，职业：Embeded Linux程式员，研发方向NAS和linux 客人呢了 ， birth ： 1980/3/28
mail :
bob_zhang2004@163.com
    或
zhanglinbao@gmail.com
  均可