が原因で呼び出し元を強制終了しないようにする必要があるコードを使用していますSIGPIPEが、実行している唯一のソケット書き込みはデータグラム ソケット (UDP と Unix ドメイン データグラム ソケットの両方) への書き込みです。心配する必要はありSIGPIPEますか？私はconnectソケットで使用していますが、(Linux での) 予備テストECONNREFUSEDでは、Unix ドメイン ソケットでリッスンしている人がいない場合、送信を開始するだけであることが示されました。UDP で何が起こるかわかりません。
すべてをハックでラップして を取り除くことができますSIGPIPEが、それが問題でない場合は、オーバーヘッドを節約し、コードの複雑さを抑えたいと思います。
答えは次の仕様にありsendます。
[EPIPE] ソケットが書き込みのためにシャットダウンされているか、ソケットが接続モードであり、接続されていません。後者の場合で、ソケットのタイプが SOCK_STREAM または SOCK_SEQPACKET で、MSG_NOSIGNAL フラグが設定されていない場合、SIGPIPE シグナルが呼び出しスレッドに生成されます。
http://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html
したがって、いいえ、データグラムソケットへの書き込みは生成されないSIGPIPEか、EPIPEエラーになります。
オープン グループと Apple は別物です。私のクラッシュログのいくつかが最近明らかにしたように、デッドUDPソケットに書き込むときにiOSでSIGPIPEを取得することは間違いなく可能です。アプリがバックグラウンドにある間、iOS は UDP ソケットを閉じる傾向があり、これらのソケットへの書き込みは SIGPIPE をポップする可能性があります。
私のクラッシュ ログから (testflightapp 提供):
Exception Latest Victim Occurrences
SIGPIPE
2 libsystem_c.dylib 0x32df47ec _sigtramp + 48
3 インスタント トーク 0x0005b10e -[IPRSNetDatagramSocket send:size:to:] (iprs_iphone_net.m:671)...
Linux、Solaris、または Windows でこれが発生したことを思い出さないでください。ただし、ソケットを閉じてから書き込みを試みたことはありません。
man 2 write私のDebianボックスによると、
EPIPE: fd は、読み取り側が閉じているパイプまたはソケットに接続されています。これが発生すると、書き込みプロセスも SIGPIPE シグナルを受け取ります。(したがって、書き込みの戻り値は、プログラムがこのシグナルをキャッチ、ブロック、または無視した場合にのみ表示されます。)
ソケットへの書き込み時に SIGPIPE を取得できるようですが、特に UDP ソケットで発生するかどうかは明らかではありません。