Hmm. test_timeout is timing out on Win98SE, but not returning an error.
In socketmodule.c's internal_connect():
static int
internal_connect(PySocketSockObject *s, struct sockaddr *addr, int addrlen)
{
int res;
res = connect(s->sock_fd, addr, addrlen);
#ifdef MS_WINDOWS
if (s->sock_timeout > 0.0) {
if (res < 0 && WSAGetLastError() == WSAEWOULDBLOCK) {
internal_select(s, 1);
res = connect(s->sock_fd, addr, addrlen);
if (res < 0) {
/* On Win98, WSAEISCONN was seen here. But
* on Win2K, WSAEINVAL. So accept both as
* meaning "fine".
*/
int code = WSAGetLastError();
if (code == WSAEISCONN ||
code == WSAEINVAL)
res = 0;
}
}
}
what happens on Win98SE is that int code is WSAEINVAL after
internal_select() times out and the second connect() call returns. But the
code here then goes out of its way to say that's not really a problem,
presumably because Win2K sets WSAEINVAL if we're actually connected at this
point. The winsock docs appear mostly silent on all of these subtleties,
and I don't have Win2K to test it on at the moment. Maybe this code has to
split into different Windows-specific flavors; or maybe Win2K also sets
WSAEINVAL in this case, in which case it will be impossible to distinguish a
successful connect from a failure to connect via this code.
BTW, does the Win2K comment look fishy to anyone else? WSAEISCONN makes a
lot more sense if we try to connect when we're already connected. Of
course, making a lot of sense doesn't bear any clear relationship to what
happens under winsock ...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4