From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | David Ford <david(at)blue-labs(dot)org>, Brent Verner <brent(at)rcfile(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [patch] helps fe-connect.c handle -EINTR more gracefully |
Date: | 2001-10-29 17:10:55 |
Message-ID: | 10353.1004375455@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I feel that if the user installed his signal handlers to interrupt system
> calls then he probably had a reason for it, possibly because of the timing
> aspects of his application. Thus, it shouldn't be libpq's task to
> override that decision.
How are we "overriding" it? A more correct description would be that
we are "coping" with it. We already do so when a send or recv is
interrupted, so I don't see why there's a problem with extending that
policy to connect calls.
What I think you are arguing is that marking signal handlers SA_RESTART
is a sufficient answer for this issue, but I don't really agree, on
two grounds: (a) not everyone has POSIX signals, (b) SA_RESTART is a
blunt instrument because it's per-signal. A user might well want
SIGALRM to interrupt some operations, but that doesn't mean he wants it
to cause failures inside subroutine libraries. Look at the backend:
we make SIGALRM non-SA_RESTART, which means we need to retry after
EINTR in most places. We do it because we want certain specific waits
to be interruptible, not because we want a global policy of "fail if
interrupted". (Now that I look at it, I wonder whether SIGINT,
SIGTERM, SIGQUIT shouldn't be non-SA_RESTART as well, but that's a
different discussion.)
My quibble with David has been about whether the fix is correct in
detail, not about whether its purpose is correct.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-10-29 17:18:55 | Re: Proposed new create command, CREATE OPERATOR CLASS |
Previous Message | George Eric R Contr AFSPC/CVYZ | 2001-10-29 16:29:59 | Re: Ultimate DB Server |