Bruce Momjian wrote:
>Here is my logic --- 99% of apps don't install a SIGPIPE signal handler,
>and 90% will not add a SIGPIPE/SIG_IGN call to their applications. I
>guess I am looking for something that would allow the performance
>benefit of not doing a pgsignal() call around very send() for the
>majority of our apps. What was the speed improvement?
>
>
Around 10% for a heavily multithreaded app on an 8-way Xeon server. Far
less for a single threaded app and far less for uniprocessor systems:
the kernel must update the pending queue of all threads and that causes
lots of contention for the (per-process) spinlock that protects the
signal handlers.
>Granted, we need to do something because our current setup isn't even
>thread-safe. Also, how is your patch more thread-safe than the old one?
>The detection is thread-safe, but I don't see how the use is.
>
First function in main():
signal(SIGPIPE, SIG_IGN);
PQsetsighandling(1);
This results in perfectly thread-safe sigpipe handling. If it's a
multithreaded app that needs correct correct per-thread delivery of
SIGPIPE signals for console IO, then the libpq user must implement the
sequence I describe below.
> If you
>still pgsignal around the calls, I don't see how two threads couldn't
>do:
>
> thread 1 thread 2
> -------- --------
> pgsignal(SIGPIPE, SIG_IGN);
> pgsignal(SIGPIPE, SIG_DFL);
> send();
> pgsignal(SIGPIPE, SIG_DFL);
>
> send();
> pgsignal(SIGPIPE, SIG_DFL);
>
>This runs thread1 with SIGPIPE as SIG_DFL.
>
>
Correct. A thread safe sequence might be something like:
pthread_sigmask(SIG_BLOCK,{SIGPIPE});
send();
if (sigpending(SIGPIPE) {
sigwait({SIGPIPE},);
}
pthread_sigmask(SIG_UNBLOCK,{SIGPIPE});
But this sequence only works for users that link against libpthread. And
the same sequence with sigprocmask is undefined for multithreaded apps.
--
Manfred
