Re: [PATCHES] SIGPIPE handling

[Manfred Spraul]

Bruce Momjian wrote:

OK, I know you had a flag for pgbench, and that doesn't use threads. 
What speedup do you see there?
 

Tiny. I added the flag to check that my implementation works, not as a 
benchmark tool.

I would not expect a library to require me to do something in my code to
be thread-safe --- either it is or it isn't.
The library is thread-safe. Just the SIGPIPE handling differs:
- single thread: handled by libpq.
- multi thread: caller must handle SIGPIPE for libpq.
Rationale: posix is broken. Per-thread signal handling is too ugly to 
think about.

Again, let's get it working perfect if they say they are going to use
threads with libpq.  Does it work OK if the app doesn't use threading?
 

No. pthread_sigmask is part of libpthread - libpq would have to link 
unconditionally against libpthread. Or use __attribute__((weak, 
alias())), but that would only work with gcc.

Does sigpending/sigwait work efficiently for threads?  Another idea is
to go with a thread-local storage boolean for each thread, and check
that in a signal handler we install.
I think installing a signal handler is not an option - libpq is a 
library, the signal handler is global.

 Seems synchronous signals like
SIGPIPE are delivered to the thread that invoked them, and we can check
thread-local storage to see if we were in a send() loop at the time of
signal delivery.
 

IMHO way to fragile.

--
   Manfred
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster