SIGCHLD(修改)

信號kill-l查看linux信號及其宏定義編號，其中1~31非實時編號（發送的信號可能丟失，不支持信號排隊），31~64實時信號，發送的信號都會被接收（支持信號排隊）
信號的定義在/usr/include/bits/signum.h
1.信號是軟件中斷
2.信號是異步信號
3.信號的來源：
(1)、硬件來源：主要是硬件的驅動產生，如鍵盤，鼠標等
(2)、軟件來源:主要是一些信號函數、比如kill()、raise()、alarm()、setitimer()等函數，軟件來源包括一些非法運算等操作，軟件設置條件(gdb調試)，信號由內核產生
#信號的處理
進程會采取三種方式響應和處理信號
1.忽略信號，sigkill和sigstop永遠不被忽略，忽略硬件異常、進程啟動時，sigusr1和sigusr2被忽略
2.執行默認操作
3.捕獲信號。告訴內核信號出現時調用自己的處理函數，SIGKILL和SIGSTOP不能被捕獲

#信號登記
void(*signal(int signo,void (*func)(int))(int)
signo--要登記的信號編號或者信號宏
func--信號處理函數指針、忽略信號（SIG_IGN）、默認信號(SIG_DEF)

今天我就不針對每個信號詳細介紹了，你也沒必要知道那么多信號，今天介紹一個很重要的信號，SIGCHLD這個信號的作用如下：

SIGCHLD?子進程狀態發生變化產生該信號（子進程運行結束）父進程調用wait函數，回收子進程的進程表項，task_struct結構體。有了這個信號父進程不需要處于阻塞狀態，任然可以干其他事情，當子進程結束時發送一個SIGCHLD信號給父進程，父進程調用wait回收子進程，避免僵尸進程的產生，提高了資源利用率。

再了解這個信號之前，先來簡單了解一下wait（）函數：

下面我們來使用信號實現解決和避免僵尸進程的第三種的方式：

這段代碼使用signal系統調用來捕獲信號，我們在signal里面注冊了SIGCHLD信號，程序中我們讓子進程現執行完，然后捕獲子進程執行完畢的信號。

下面是運行結果部分截圖：

這里進程pid3546為父進程3547為子進程

我們再次運行程序來觀察程序的運行狀態，把程序編譯gcc signal_sigchld.c -o child

運行程序./child

使用命令ps -aux|grep child 來觀察程序運行狀態，下面是結果截圖

你可以看到父子進程在子進程運行到20以前都處于S+即運行狀態，當子進程到達20的時候，signal捕獲到子進程退出的信號SIGCHLD

這時候子進程狀態變為Z+即僵尸進程。

所以我們說了那么多，為什么SIGCHLD沒有處理這個僵尸進程呢，這里我們要搞清楚，SIGCHLD只是子進程在運行結束的時候產生的一i個信號，我們要想處理這個僵尸狀態，還是要用到上面說的兩種方式。最好就是父進程調用wait(),你可能有要問，既然都要用到wait，那抹干嗎多此一舉使用信號呢？首先要知道父進程調用wait以后處于阻塞狀態，父進程不能干其他事情，使用效率降低，資源利用率低下，增加了開銷，而調用信號以后，當子進程執行完畢以后，自動產再生一個信號給父進程，父進程收到信號以后就調用wait揮手子進程沒有釋放的資源。這樣我的感覺就是子進程化被動為主動。父進程的工作也輕松了不少，可以做自己想做的事情。

所以為了避免僵尸進程的產生我們修改上面的代碼中的sig_handler函數如下：

當父進程捕獲到SIGCHLD后調用wait。

按照上述步驟重新編譯，運行，用ps觀察進程運行狀態：

上面是子進程運行到20之前，下面看子進程運行完畢，父進程捕獲到SIGCHLD以后

這里你發現子進程沒有顯示，是因為紫禁城已經被回收釋放掉了。

這就是處理僵尸進程的第三種方式。

也是一種異步處理方式。