管道破裂的原因解釋如下

拷貝黏貼

我寫了一個服務器程序,在Linux下測試，然后用C++寫了客戶端用千萬級別數量的短鏈接進行壓力測試.?但是服務器總是莫名退出，沒有core文件.

最后問題確定為, 對一個對端已經關閉的socket調用兩次write, 第二次將會生成SIGPIPE信號, 該信號默認結束進程.

具體的分析可以結合TCP的"四次握手"關閉. TCP是全雙工的信道, 可以看作兩條單工信道, TCP連接兩端的兩個端點各負責一條. 當對端調用close時, 雖然本意是關閉整個兩條信道, 但本端只是收到FIN包. 按照TCP協議的語義, 表示對端只是關閉了其所負責的那一條單工信道, 仍然可以繼續接收數據. 也就是說, 因為TCP協議的限制, 一個端點無法獲知對端的socket是調用了close還是shutdown.

對一個已經收到FIN包的socket調用read方法, 如果接收緩沖已空, 則返回0, 這就是常說的表示連接關閉. 但第一次對其調用write方法時, 如果發送緩沖沒問題, 會返回正確寫入(發送). 但發送的報文會導致對端發送RST報文, 因為對端的socket已經調用了close, 完全關閉, 既不發送, 也不接收數據. 所以, 第二次調用write方法(假設在收到RST之后), 會生成SIGPIPE信號, 導致進程退出.

解決方案也提供了。如下

系統里邊定義了三種處理方法：(1)SIG_DFL信號專用的默認動作:(a)如果默認動作是暫停線程，則該線程的執行被暫時掛起。當線程暫停期間，發送給線程的任何附加信號都不交付，直到該線程開始執行，但是SIGKILL除外。(b)把掛起信號的信號動作設置成SIG_DFL，且其默認動作是忽略信號 (SIGCHLD)。(2)SIG_IGN忽略信號(a)該信號的交付對線程沒有影響(b)系統不允許把SIGKILL或SIGTOP信號的動作設置為SIG_DFL3)SIG_ERR項目中我調用了signal(SIGPIPE,SIG_IGN), 這樣產生SIGPIPE信號時就不會中止程序，直接把這個信號忽略掉。

總結

以上是生活随笔為你收集整理的linux下软件如何防破裂,linux下管道破裂的處理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。