>
>
>
>It wouldn't surprise me in the least if this behavior is
>platform-dependent.  It may well be that David's kernel will allow
>connect() to be interrupted by SIGALRM while yours won't.  (Which
>reminds me that neither of you specified what platforms you were
>testing on.  For shame.)  Or maybe the difference depends on whether
>you are trying to connect to a local or remote server.
>
>Unless someone can point out a situation where retrying connect()
>after EINTR is actively bad, my inclination is to accept the patch.
>It seems like a net improvement in robustness to me, with no evident
>downside other than a line or two more code.
>

I didn't specify my OS because this sort of a thing is standard *nix etc 
design (well, m$ excluded of course).

I use Linux.  Every *nix that I know of can have system calls be 
interrupted.

Please wait a day before applying the patch, I want to make it a bit 
more clean/readable and make sure I covered everything in fe-connect.c, 
I found that the SSL functions are traversed even if ssl is turned off 
in the config file and I have to handle that too.

David



Fri, 26 Oct 2001 00:58:14 -0400
David Ford <david@blue-labs.org>
Re: [patch] helps fe-connect.c handle -EINTR more gracefully
David Ford <david@blue-labs.org> writes:
> Please wait a day before applying the patch, I want to make it a bit 
> more clean/readable and make sure I covered everything in fe-connect.c, 

BTW, reading the HPUX man page for connect I find the following relevant
error codes:

          [EALREADY]               Nonblocking I/O is enabled with
                                   O_NONBLOCK, O_NDELAY, or FIOSNBIO, and a
                                   previous connection attempt has not yet
                                   completed.

          [EINPROGRESS]            Nonblocking I/O is enabled using
                                   O_NONBLOCK, O_NDELAY, or FIOSNBIO, and
                                   the connection cannot be completed
                                   immediately.  This is not a failure.
                                   Make the connect() call again a few
                                   seconds later.  Alternatively, wait for
                                   completion by calling select() and
                                   selecting for write.

          [EINTR]                  The connect was interrupted by a signal
                                   before the connect sequence was
                                   complete.  The building of the
                                   connection still takes place, even
                                   though the user is not blocked on the
                                   connect() call.

          [EISCONN]                The socket is already connected.

This does not actually *say* that the appropriate behavior after EINTR
is to retry, but reading between the lines one might infer that it will
work like the nonblocking case, wherein a retry of connect tries to link
to the existing connection attempt, not start a new one.

What's more important is that a retry will expose the possibility of
getting EALREADY or EISCONN.  EALREADY certainly must be treated as
success the same as EINPROGRESS (if it exists on a given platform ---
better #ifdef it I think).  Not so sure about EISCONN; does that imply
"you moron, this socket's been open forever", or does it get returned on
the first iteration that doesn't return EALREADY?

			regards, tom lane

Fri, 26 Oct 2001 10:46:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [patch] helps fe-connect.c handle -EINTR more gracefully 