Re: [patch] helps fe-connect.c handle -EINTR more gracefully

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

In response to

Responses

Browse pgsql-hackers by date

  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