Re: SIGPIPE handling

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