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

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

In response to

Responses

Browse pgsql-hackers by date

  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