On Tue, 14 Mar 2000, Matthew Cline wrote:
> In WINSOCK_connect(), if a connect() call returns EINPROGRESS for
> a non-blocking socket, then it sets the last error to
> WSAEWOULDBLOCK and returns SOCKET_ERROR. But isn't EINPROGRESS
> normal for a connect() on a non-blocking socket?
Yup.
> I changed the
> behavior so that it would report a connect success for EINPROGRESS
> on a non-blocking socket, and this seemed to make wine behave
> somewhat better. Is this the right thing to do?
No. Winsock returns WSAEWOULDBLOCK where Unix returns EINPROGRESS, with
basically exactly the same semantics. (And WSAEINPROGRESS means that a
blocking operation is already in progress, MS really got it backwards)
>From MSDN:
Return Values
If no error occurs, connect returns zero. Otherwise, it returns
SOCKET_ERROR, and a specific error code can be retrieved by calling
WSAGetLastError.
On a blocking socket, the return value indicates success or failure of the
connection attempt.
With a nonblocking socket, the connection attempt cannot be completed
immediately. In this case, connect will return SOCKET_ERROR, and
WSAGetLastError will return WSAEWOULDBLOCK. In this case, there are three
possible scenarios:
Use the select function to determine the completion of the
connection request by checking to see if the socket is writeable.
If the application is using WSAAsyncSelect to indicate interest in
connection events, then the application will receive an FD_CONNECT
notification indicating that the connect operation is complete
(successfully or not).
If the application is using WSAEventSelect to indicate interest in
connection events, then the associated event object will be signaled
indicating that the connect operation is complete (successfully or not).
[...]
Remarks
[...]
For connection-oriented, nonblocking sockets, it is often not possible to
complete the connection immediately. In such a case, this function returns
the error WSAEWOULDBLOCK. However, the operation proceeds.
