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@gmx.net http://funkturm.homeip.net/~peter
