Manfred Spraul wrote:
Bruce Momjian wrote:
+ /*
+* We could lose a signal during this test.
+* In a multi-threaded application, this might
+* be a problem. Do any non-threaded platforms
Threaded or non-threaded?
OK, yea, I will use threaded.
+*
Manfred Spraul wrote:
Bruce Momjian wrote:
+ /*
+* We could lose a signal during this test.
+* In a multi-threaded application, this might
+* be a problem. Do any non-threaded platforms
Threaded or non-threaded?
+* lack sigaction()?
+*/
Here is my solution to ignoring SIGPIPE in libpq's send() for threaded
apps.
It defines a custom SIGPIPE handler if one is not already defined by the
application, and uses a thread-local variable that is checked in the
SIGPIPE handler to know if the SIGPIPE was caused by a libpq send()
call.
One issue I had is in the following function. How can I easily find the
current signal value without causing possible signal loss during
testing, or possible abort if signals were previously ignored. I could
use sigblock, and I think that would exist on a system that doesn't have
sigaction, but
Bruce Momjian wrote:
+ /*
+* We could lose a signal during this test.
+* In a multi-threaded application, this might
+* be a problem. Do any non-threaded platforms
Threaded or non-threaded?
+* lack sigaction()?
+*/
Additionally, the
Attached is my idea for implementing safe SIGPIPE in threaded apps. The
code has the same libpq behavior if not compiled using
--enable-thread-safety.
If compiled with that option, an app wanting to define its own SIGPIPE
handler has to do so before connecting to a database. On first
Manfred Spraul wrote:
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
Hi,
attached is an update of my automatic sigaction patch: I've moved the
actual sigaction calls into pqsignal.c and added a helper function
(pgsignalinquire(signo)). I couldn't remove the include signal.h from
fe-connect.c: it's required for the SIGPIPE definition.
Additionally I've added a
Better. However, I am confused over when we do sigaction. I thought we
were going to do it only if they had a signal handler defined, meaning
if (pipehandler != SIG_DFL
pipehandler != SIG_IGN
pipehandler != SIG_ERR)
conn-do_sigaction = true;
Bruce Momjian [EMAIL PROTECTED] writes:
Is running the rest of the
application with SIGPIPE = SIG_IGN a problem?
That is NOT an acceptable thing for a library to do.
regards, tom lane
---(end of broadcast)---
TIP 1:
On Sun, Nov 16, 2003 at 06:28:06PM +0100, Kurt Roeckx wrote:
On Sun, Nov 16, 2003 at 12:56:10PM +0100, Manfred Spraul wrote:
Hi,
attached is an update of my automatic sigaction patch: I've moved the
actual sigaction calls into pqsignal.c and added a helper function
Manfred Spraul [EMAIL PROTECTED] writes:
But how should libpq notice that the caller handles sigpipe signals?
a) autodetection - if the sigpipe handler is not the default, then the
caller knows what he's doing.
b) a new PGsetsignalhandler() function.
c) an additional flag passed to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is running the rest of the
application with SIGPIPE = SIG_IGN a problem?
That is NOT an acceptable thing for a library to do.
Yes, I was afraid of that. Here's another idea. If the signal handler
is SIG_DFL, we install our own
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
But how should libpq notice that the caller handles sigpipe signals?
a) autodetection - if the sigpipe handler is not the default, then the
caller knows what he's doing.
b) a new PGsetsignalhandler() function.
c) an additional
Bruce Momjian wrote:
I thought it should be global too, basically testing on the first
connection request.
What if two PQconnect calls happen at the same time?
I would really prefer the manual approach with a new PQsetsighandler
function - the autodetection is fragile, it's trivial to find a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I was afraid of that. Here's another idea. If the signal handler
is SIG_DFL, we install our own signal handler for SIGPIPE, and set/clear a
global variable before/after we send().
That would address the speed issue but not
Manfred Spraul wrote:
Bruce Momjian wrote:
I thought it should be global too, basically testing on the first
connection request.
What if two PQconnect calls happen at the same time?
I would really prefer the manual approach with a new PQsetsighandler
function - the autodetection is
Gaetano Mendola wrote:
Bruce Momjian wrote:
I think this is the patch I like. It does the auto-detect handling as I
hoped. I will just do the doc updates to mention it.
My only issue is that this is per-connection, while I think you have to
create a global variable that defaults to false, and
Tom Lane wrote:
I don't think we need to complicate pqsignal's API for this. Instead
we'd better document that SIGPIPE handling has to be set up and kept
stable before doing any libpq operations in a multithread app.
Not reliable.
An app could install it's own signal handler and block SIGPIPE
Sorry, but this just seems overdesigned. I liked Tom's suggestion:
One possibility that comes to mind is simply to test whether the SIGPIPE
handler is already SIG_IGN before we munge it. Ideally we'd do that
once when the conn object is created, but even if it had to be done more
often, it
I think this is the patch I like. It does the auto-detect handling as I
hoped. I will just do the doc updates to mention it.
My only issue is that this is per-connection, while I think you have to
create a global variable that defaults to false, and on first connect,
check, and not after.
Attatched is the latest version of my patch that makes the
signal(SIG_PIPE, SIG_IGN) calls around the send() syscall conditional:
they are not sufficient to ensure that multithreaded libpq users are not
killed by SIGPIPE signals, and they cause a noticable slowdown.
I've switched to a global
pqsecure_write tries to catch SIGPIPE signals generated by network
disconnects by setting the signal handler to SIG_IGN. The current
approach causes several problems:
- it always sets SA_RESTART when it restores the old handler.
- it's not reliable for multi threaded apps, because another thread
23 matches
Mail list logo