轉載請註明 出自：http://www.cppblog.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個僵死程序。那麼怎麼解決這個問題呢？~。。。。