Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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.
Right. > 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 Yes, that is the logic in my patch, except that I don't check errno, I just call sigpending(). There are a few writes and it seemed impossible to check them all. Also, we might get a SIGPIPE but as you mentioned the SIGPIPE may have been ignored. > 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. Right. > 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. Right. > 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? Right. We could add a sigpending() check and if set we just don't clear the SIGPIPE signal, but this adds an additional function call into the mix that seemed unnecessary, though I could be convinced otherwise. > This seems workable as long as we document the possible gotchas. My patch documents the limitation. I finished reading the Addison-Wesley "Programming with POSIX Threads" book and it has helped me with this stuff. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly