Peter Eisentraut wrote:
>>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.
>
My patch doesn't affect signal handling, my patch affects the response
of connect() after it is interrupted by a signal.
>>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.
>
Let me ask you how you would handle SIGALRM without interrupting
syscalls? Further, how would you guarantee your SIGALRM handler would
execute within your granular limits?
Yes, the user has a timing aspect. Libpq isn't overriding it and my
patch doesn't change that. My patch adds the EINTR handling. Currently
there is no way for libpq to continue processing a connect call if that
syscall is interrupted and the user is using POSIX defaults. Please
refer to the POSIX specification, I povided a quote in a previous message.
POSIX default signal handling sets SA_RESTART which -disables- system
call restart.
At present, the PQconnect* function treats EINTR as a fatal error.
David
