http://blog.csdn.net/anghlq/article/details/5990513
在Unix系統下，如果send 、 recv 、 write在等待協議傳送數據時 ， socket 被 shutdown，調用send的進程會接收到一個SIGPIPE信號，進程對該信號的默認處理是進程終止。 此種情況 應用就很難查 出 處理進程為什么退出。
SIGPIPE 信號：
對 一個已經收到FIN包的socket調用read方法, 如果接收緩沖已空, 則返回0, 這就是常說的表示連接關閉. 但第一次對其調用write方法 時, 如果發送緩沖沒問題, 會返回正確寫入(發送). 但發送的報文會導致對端發送RST報文, 因為對端的socket已經調用了close, 完全 關閉, 既不發送, 也不接收數據. 所以, 第二次調用write方法(假設在收到RST之后), 會生成SIGPIPE信號, 導致進程退出 。如果對 SIGPIPE 進行忽略處理， 二次調用write方法時, 會返回-1, 同時errno置為SIGPIPE.
處理方法：
在初始化時調用 signal(SIGPIPE,SIG_IGN) 忽略該信號（只需一次） ， SIGPIPE交給了系統處理。 此時 send 、 recv 或 write 函數將返回-1，errno為EPIPE，可視情況關閉socket或其他處理
SIGPIPE 被忽略的情況下，如果 服務器采用了fork的話，要收集垃圾進程，防止僵屍進程的產生，可以這樣處理： signal(SIGCHLD,SIG_IGN); 交給系統init去回收。 這樣 子進程就不會產生僵屍進程了。
在Linux環境下開發經常會碰到很多錯誤(設置errno)，其中EAGAIN是其中比較常見的一個錯誤(比如用在非阻塞操作中)。
從字面上來看，是提示再試一次。這個錯誤經常出現在當應用程序進行一些非阻塞(non-blocking)操作(對文件或socket)的時候。例如，以 O_NONBLOCK的標志打開文件/socket/FIFO，如果你連續做read操作而沒有數據可讀。此時程序不會阻塞起來等待數據准備就緒返 回，read函數會返回一個錯誤EAGAIN，提示你的應用程序現在沒有數據可讀請稍后再試。
又例如，當一個系統調用(比如fork)因為沒有足夠的資源(比如虛擬內存)而執行失敗，返回EAGAIN提示其再調用一次(也許下次就能成功)。
Linux - 非阻塞socket編程處理EAGAIN錯誤
在linux進行非阻塞的socket接收數據時經常出現Resource temporarily unavailable，errno代碼為11(EAGAIN)，這是什么意思？
這表明你在非阻塞模式下調用了阻塞操作，在該操作沒有完成就返回這個錯誤，這個錯誤不會破壞socket的同步，不用管它，下次循環接着recv就可以。 對非阻塞socket而言，EAGAIN不是一種錯誤。在VxWorks和Windows上，EAGAIN的名字叫做EWOULDBLOCK。
另外，如果出現EINTR即errno為4，錯誤描述Interrupted system call，操作也應該繼續。
最后，如果recv的返回值為0，那表明連接已經斷開，我們的接收操作也應該結束。
當客戶通過Socket提供的send函數發送大的數據包時，就可能返回一個EGGAIN的錯誤。該錯誤產生的原因是由於send
函數 中的size變量大小超過了tcp_sendspace的值。tcp_sendspace定義了應用在調用send之前能夠在kernel中緩存的數據 量。當應用程序在socket中設置了O_NDELAY或者O_NONBLOCK屬性后，如果發送緩存被占滿，send就會返回EAGAIN的錯誤。
為了消除該錯誤，有三種方法可以選擇：
1.調大tcp_sendspace，使之大於send中的size參數
---no -p -o tcp_sendspace=65536
2.在調用send前，在setsockopt函數中為SNDBUF設置更大的值
1.你自己的緩沖區滿了，會返回EAGAIN。
2.你的沒滿，對方的緩沖區滿了,肯定不關你事，可能會發送不成功，但是協議棧提供的系統調用，只管數據成功從你的緩沖區發出去，之后人家因為緩沖區滿收不到數據，tcp自己有重傳機制（參考Tcp/ip詳解卷1）。