How to handle SIGPIPE when writing to broken socket

[bogertron]

I am writing something which attempts to send a message over a TCP connection. I have come across an issue where the connection might break. When this occurs, HPUX throws a sigpipe and sets errno appropriately.

I am having an issue with the signal that is generated. If I want to create a library which handles this, that means that I need to add a signal handler for SIGPIPE within a shared object. I have also attempted to block signals within my own thread by pthread_sigmask. However, this requires my library, and consequentially, executables consuming my API to link with the pthread library.

Is there a more elegant way to do this? Or is there no way around it?

[Dennis Handly]

Any reason you don't block or ignore all SIGPIPEs?

>I have also attempted to block signals within my own thread by pthread_sigmask. However, this requires my library, and consequentially, executables consuming my API to link with the pthread library.

Why do you think you have threads?  If you have threads, then the application already is linked with libpthread.

There may already be stubs in libc for pthread_sigmask?

[bogertron]

The only reason that I can think is that the linking application might want to do some action when it receives a SIGPIPE. I do not want my handlers to potentially catch their signals. I also do not want to go the other way and have them catch my signals.

I currently use pthread_sigmask in the event that the linking application might be multithreaded (already link with pthread). But I would like to avoid having pthread be a requirement for linking with my library.

I did notice that pthread_sigmask does have stubs in libc, however, they are stubs, and do not seem to block any threads (or it could have been a mistake on my part for not getting the desired behavior).

[Dennis Handly]

>I do not want my handlers to potentially catch their signals. I also do not want to go the other way and have them catch my signals.

Well, unless you are in a separate thread, there is no good way to know which is yours vs theirs unless you continually set and reset them.

>I would like to avoid having pthread be a requirement for linking with my library.

With the stubs, you don't need to care, too much.

>do not seem to block any threads

That's correct, pthread_sigmask returns 0.  You need to have a plan B that detects if you aren't in a thread.