> > > >No, it should *not* look like that. The fe-connect.c code is designed >to move on as soon as it's convinced that the kernel has accepted the >connection request. We use a non-blocking connect() call and later >wait for connection complete by probing the select() status. Looping >on the connect() itself would be a busy-wait, which would be antisocial. >
The fe-connect.c code moves on regardless of the completion of the connect() if it has been interrupted. To simplify, in a program without SIGALRM events, PQconnect* won't be interrupted. The connect() call will complete properly. In a program with SIGALRM events, the call is interrupted inside connect(). If SA_RESTART was disabled for connect() in POSIX semantics, the program would automatically jump right back into the connect() call. However by default POSIX code enables SA_RESTART which for SIGALRM means -don't- automatically restart the system call. This means the programmer needs to check for -1/errno=EINTR and jump back into connect() himself. There isn't a concern for busy wait/anti social code behavior, your program was in the middle of connect() when it was interrupted, you're simply jumping back to where you left off. It doesn't matter if it is a blocking connect or non-blocking connect, handling EINTR must be done if SIGALRM events are employed. A fast enough event timer with a non-blocking connect will also be susceptible to EINTR. EINTR is distinctly different from EINPROGRESS. If they were the same then there would be a problem. EINTR should be handled by jumping back into the connect() call, it is re-entrant and designed for this. Regardless, you don't wait for the connection to complete, the code following the connect() call returns failure for every -1 result from connect() unless it is EINPROGRESS or EWOULDBLOCK. select() is -not- used in fe-connect.c. It is possible with the current code for the connection to fail in non-blocking mode. Reason: you call connect() in non-blocking mode, break out of the section on EINPROGRESS, and continue assuming that the connection will be successful. EINPROGRESS The socket is non-blocking and the connection can not be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure). The socket is not checked any further after the connect(). The code should not continue on into the SSL handling until you're sure that the socket is ready for operation. The reason why I am getting EINTR from a non-blocking connect is because my event timer happens to fire in the middle of the connect() call. Just because you set the socket to FIONBIO doesn't mean that connect() can't be interrupted. David ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]