While developing Humail we had a sever problem that caused the app to crash. We were using an open source mail library called libEtPan which was throwing SIGPIPE signal when the connection with the remote mail server is interrupted, ended or timed-out. We sent a email to Apple and we did not get response. After a lot of investigations and trying out available solutions at no good we found that the solution mentioned here work. After around 10 days we found the solution we got apple response and here you are:
I'm responding to your question about how to handle or ignore SIGPIPE in an iOS application. While I've seen some odd behavior with SIGPIPE on iOS in the past, everything seems to be working as expected now. The attached test program demonstrates three different ways to deal with SIGPIPE:
A. does nothing -- If you tap the "nothing" button, the program does nothing special, and thus crashes when it receives the SIGPIPE.
B. SIG_IGN -- If you tap the SIG_IGN button, the program uses signal (SIGPIPE, SIG_IGN) to disable SIGPIPE globally.
C. SO_NOPIPE -- If you tap the SO_NOPIPE button, the program uses the SO_NOPIPE socket option to disable SIGPIPE on the sockets it uses.
I tested this program on iOS 3.1.3, iOS 4.0, and iOS 4.2. All cases worked as expected when I ran the app from Springboard. One gotcha is that, when you run from Xcode, the debugger still sees the SIGPIPE in case B. This is an artefact of how the debugger interacts with signal delivery. It's perfectly OK to hit the continue button, after which the program will just ignore the SIGPIPE.
In general I recommend that you use SO_NOPIPE (option C) to get around SIGPIPE problems. I've never had any problems with SO_NOPIPE working as expected on iOS (in fact, it's used by numerous iOS subsystems, like CFNetwork). Beyond that, it has some nice features:
o SO_NOPIPE places the handling of SIGPIPE under the control of the code that created the socket, which is the most sensible place to control this sort of thing.
o Because the signal is never generated, the debugger never sees it, preventing the gotcha described above.
In contrast, the signal disposition (that which you change in option B) is a global setting within your process, which makes it inappropriate for library code to change and inconvenient in general.
Let me know if you have further problems with this.
Share and Enjoy
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
I included the attachment here for your convenience.
BTW, note that there is a small typo in Apple email. It is called SO_NOSIGPIPE and not SO_NOPIPE