Re: libpq and psql not on same page about SIGPIPE

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
> we could also check errno for SIGPIPE rather than calling sigpending.

> He has a concern about an application that already blocked SIGPIPE and
> has a pending SIGPIPE signal waiting already. One idea would be to
> check for sigpending() before the send() and clear the signal only if
> SIGPIPE wasn't pending before the call. I realize that if our send()
> also generates a SIGPIPE it would remove the previous realtime signal
> info but that seems a minor problem.

Supposing that we don't touch the signal handler at all, then it is
possible that the application has set it to SIG_IGN, in which case a
SIGPIPE would be discarded rather than going into the pending mask.
So I think the logic has to be:

pthread_sigmask to block SIGPIPE and save existing signal mask

send();

if (errno == EPIPE)
{
if (sigpending indicates SIGPIPE pending)
use sigwait to clear SIGPIPE;
}

pthread_sigmask to restore prior signal mask

The only case that is problematic is where the application had
already blocked SIGPIPE and there is a pending SIGPIPE signal when
we are entered, *and* we get SIGPIPE ourselves.

If the C library does not support queued signals then our sigwait will
clear both our own EPIPE and the pending signal. This is annoying but
it doesn't seem fatal --- if the app is writing on a closed pipe then
it'll probably try it again later and get the signal again.

If the C library does support queued signals then we will read the
existing SIGPIPE condition and leave our own signal in the queue. This
is no problem to the extent that one pending SIGPIPE looks just like
another --- does anyone know of platforms where there is additional info
carried by a SIGPIPE event?

This seems workable as long as we document the possible gotchas.

regards, tom lane