Re: libpq and psql not on same page about SIGPIPE

Tom Lane wrote:

>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?
>
>
>
Linux stores pid/uid together with the signal. pid doesn't matter and no
sane programmer will look at the uid, so it seems to be possible.

>This seems workable as long as we document the possible gotchas.
>
>
>
Is that really worthwhile? There are half a dozend assumption about the
C library and kernel internal efficiency of the signal handling
functions in the proposal. Adding a PQinitLib function is obviously a
larger change, but it solves the problem.
I'm aware of one minor gotcha: PQinSend() is not usable right now: it
relies on the initialization of pq_thread_in_send, which is only created
in the middle of the first connectDB(). That makes proper signal
handling for the first connection impossible.

--
Manfred