For Posix platforms the current common qpid library code sets the signal status of the SIGPIPE signal to be ignored, so that disconnecting a socket from the remote end then writing to it doesn't cause a SIGPIPE which has a default handler which terminates the process.

For the broker this is completely ok.

However for the client library code this is not really a good plan, because we have no idea what the client code itself might be doing and ignoring SIGPIPE for the whole process might mess up something the application is trying to do.

There are no entirely portable solutions to this.
MSG_NOSIGNAL - some platforms support a flag for send() which stops the socket from raising the SIGPIPE signal on a send by send basis.
SO_NOSIGPIPE - Other platforms support a socket option which can be set on a socket to stop it generating SIGPIPE at all.

Linux supports MSG_NOSIGNAL 
FreeBSD both MSG_NOSIGNAL and SO_NOSIGPIPE
MacOS is documented to support SO_NOSIGPIPE on recent versions, but not documented to support MSG_NOSIGNAL
Solaris does not seem to support either!

There appears to be another solution to this problem which is more portable - 

The SIGPIPE is supposed to only be sent to the thread that has performed the write()/send() that caused it so it should only need to be blocked in that thread itself. The write()/send() will return EPIPE if the signal would be sent and is blocked (or is ignored). So we could roughly speaking just block SIGPIPE around the send() calls themselves.