From: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: SIGPIPE handling |
Date: | 2003-11-17 17:59:55 |
Message-ID: | 3FB90C9B.4030304@colorfullife.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-11-17 18:39:43 | Re: LISTEN/NOTIFY regression tests |
Previous Message | Bruce Momjian | 2003-11-17 15:47:21 | Re: SIGPIPE handling |