connect(2) on Windows may still be triggered twice
Details
As seen in https://ci.appveyor.com/project/YorickPeterse/inko/builds/24468777/job/3wgmkdt5kgx10vwd, calls to connect(2)
on Windows may still happen multiple times, resulting in a EISCONN error being produced. The
documentation of connect(2)
on Windows lists the following possible (relevant) errors for non-blocking sockets:
- WSAEINPROGRESS
- WSAEALREADY: raised when trying to connect again
- WSAEISCONN: same
- WSAEWOULDBLOCK
There is also the following section:
Until the connection attempt completes on a nonblocking socket, all subsequent calls to connect on the same socket will fail with the error code WSAEALREADY, and WSAEISCONN when the connection completes successfully. Due to ambiguities in version 1.1 of the Windows Sockets specification, error codes returned from connect while a connection is already pending may vary among implementations. As a result, it is not recommended that applications use multiple calls to connect to detect connection completion. If they do, they must be prepared to handle WSAEINVAL and WSAEWOULDBLOCK error values the same way that they handle WSAEALREADY, to assure robust operation.
We already handle WSAEWOULDBLOCK, as well as WSAEINPROGRESS. It's possible we're using the wrong constant (the winapi crate provides WSAEINPROGRESS twice in different modules). It's also possible that if e.kind() == io::ErrorKind::WouldBlock
produces false
if Rust uses a different ErrorKind
on Windows for some reason.
Expected behaviour
Connecting a socket never produces EISCONN.
Actual behaviour
Sometimes on Windows this does happen, but never on Linux or Mac (at least so far).