Avoid triggering SIGPIPE in library code
commit01d1b53445d9c8c23108449ed945cb39df2307bf
authorOlly Betts <olly@survex.com>
Mon, 9 Oct 2023 23:17:02 +0000 (10 12:17 +1300)
committerOlly Betts <olly@survex.com>
Mon, 9 Oct 2023 23:17:02 +0000 (10 12:17 +1300)
treefbf9871d32eeca9cf786e55c66f77e09b1039561
parent9860ddbb620de1d3596da55b71df5d5aad92968b
Avoid triggering SIGPIPE in library code

On Unix-like platforms we want to avoid generating SIGPIPE when writing
to a socket when the other end has been closed since signals break the
encapsulation of what we're doing inside the library - either user code
would need to handle the SIGPIPE, or we set a signal handler for SIGPIPE
but that would handle *any* SIGPIPE in the process, not just those we
might trigger, and that could break user code which expects to trigger
and handle SIGPIPE.

We don't need SIGPIPE since we can check errno==EPIPE instead (which is
actually simpler to do).

It seems all current Unix-like platforms now support SO_NOSIGPIPE or
MSG_NOSIGNAL, so currently we just fall back to setting SIGPIPE to
SIG_IGN.  If there are actually current platforms which have SIGPIPE
without SO_NOSIGPIPE or MSG_NOSIGNAL then we can look at other ways to
avoid generating the signal.
xapian-core/backends/remote/remote-database.cc
xapian-core/net/remoteconnection.cc
xapian-core/net/remoteserver.cc