轉載請注明 出自：http://m.shnenglu.com/mysileng/archive/2013/01/11/197202.html

     討論兩個由sigchld信號引起的血案問題，討論的環境是服務端的并發程序。我們先把最原始的服務器端并發程序模型貼出來：

     以上是服務器端程序，我們先不看被注視掉的部分，程序對于每一個accept的TCP連接會產生一個子進程，交給子進程去處理。而子進程其實并不做什么，直接睡眠3秒就結束?？梢韵胂筮@樣當子進程exit以后，會給父進程發sigchld信號，通知父進程自己掛了。但是在我們的父進程中，我們對于sigchld信號采用默認處置(忽略)。結果可想而知就是來一個連接，就產生一個僵死進程。我們運行程序3次，看看是否會得到3個僵死進程。
服務器端運行程序，被某客戶端連接3次：

客戶端運行程序執行3次，并查看進程情況:

    首先聲明，我們用客戶端可以查看服務器端進程的原因是，我們把客戶端和服務端放在了一臺電腦上進程本次試驗。我們并不關心cli客戶端的具體實現，因為服務器并不從客戶端獲取任何信息。
    從結果可知，果然服務端果斷產生了3個僵死進程。接下來我們加上對sigchld的處理程序。但加上以后也將產生我們的第一個血案：

白色為客戶端，黑為服務端:

    可見，僵死進程的問題已經解決，但還有個潛在的隱藏危機。
    PHOSIX對于向accept這種慢速的系統系統調用有一個基本規則(apue,unp都有涉及)：當進程阻塞于某個慢系統調用的時候(我們的程序是accept)，當進程捕捉到某個信號(我們的程序是sigchld)，并從信號的處理函數返回時(我的程序是deal函數),進程不再阻塞與之前的慢速系統調用，而是返回一個EINTER錯誤。
     對于上面的這個規則，各個操作系統的對待方式是不同的。有的操作系統返回EINTER以后，就會自動重啟之前的慢速系統調用而繼續，有些則不會自動重啟。對我們實驗程序的這個操作系統環境(centos5.5)，從結果來看,因為并沒打印"accept error"并退出程序，我猜想，centos5.5應該是會自動重啟慢速系統調用的。也就是說在這里我因為操作系統的優秀，躲過一劫(躲過第一次血案)。但為了可移植性我們應該改進程序為以下實現：

    我的改動主要集中在對accpt的錯誤處理里面。接下來闡述另外一個血案
----------------------------------------------------------------------------
    我們繼續沿用上述的最后一次服務端程序來進行接下來的實驗，現在我們編寫一個客戶端程序，客戶端一次性跟服務端申請5個連接。客戶端的程序如下:

   整個程序的構架大概如下:

    這里客戶端最需要注意的是程序的最后一句并不是一個個close所有的套接字描述符，而是調用exit程序結束進程。根據APUE描述，exit系統調用會執行關閉該進程所有描述符的操作，也就是說客戶端的所有描述符，包括套接字描述符也被幾乎同時關閉了。也就是說服務端的由監聽進程產生的所有處理子進程也會在幾乎同時死掉。那么就會在幾乎同時給父進程發送sigchld信號。情況如下:

    血案即將發生。請注意，根據APUE對于信號在1-31之內的的信號，因為歷史原因，是不可靠信號，也就說，SIGCHLD信號在被遞送到正在阻塞SIGCHLD信號的進程時，是不會排隊的，而是會被系統壓縮。上述問題就是當5個sigchld信號幾乎同時到達父進程時，只有第一個能順利被父進程的信號處理函數處理。又因為被signal/sigaction設置的信號處理函數會自動阻塞正在處理的信號這一原則，接下來沒被處理的4個sigchld信號，被排在了父進程門口。不巧的是，sigchld又是不可靠信號，結果是4個sigchld被壓縮成一個sigchld信號。這就導致信號的丟失。也因為丟失了3個sigchld信號，就會產生3個僵尸進程。你說這是不是一個名符其實的血案。接下來我們實驗一下：

    可以清晰的看到結果如預期，所有出現信號丟失導致3個僵死進程。那么怎么解決這個問題呢？~。。。。