From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-28 19:16:05 |
Message-ID: | Pine.LNX.4.30.0110281348510.619-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> AFAICT the client-side libpq doesn't (and shouldn't) touch signal
> handling at all, except for a couple of places in the print routines
> that temporarily block SIGPIPE.
Which was my point.
> Since we deal happily with EINTR for most of the frontend socket calls,
> I don't see a reason not to cope with it for connect() too. I am
> somewhat concerned about what exactly it means for a non-blocking
> connect, however. Maybe it doesn't mean anything, and we could treat
> it the same as EINPROGRESS.
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. If the user doesn't want system calls to be
interrupted, then he should install the signal handlers in the proper way.
If he doesn't know how to do that, he needs to educate himself, that's
all.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2001-10-28 19:18:41 | Re: Ultimate DB Server |
Previous Message | Olivier PRENANT | 2001-10-28 18:32:11 | Regression error on unixware 7 and open unix 8 |