Tim Peters wrote: > Anyone: is it "a bug" or "a feature" that a socket.connect() call > that times out may raise either socket.timeout or socket.error? > Trent's box raises socket.error. On my box, when I set a timeout > value small enough so that it _does_ time out, socket.timeout is > raised: That should give another clue as to what happened: It is *not* the select call that timed out - this would have raised a socket_timeout exception, due to internal_connect setting the timeout variable. Looking at the code, the following operations might have caused this error 10060: - getsockaddrarg - connect, returning WSAETIMEDOUT instead of WSAEWOULDBLOCK The code in getsockaddrarg is hard to follow, but I think it should only ever cause socket.gaierror. So why would connect ignore the non-blocking mode? the earlier call to ioctlsocket might have failed - unfortunately, we wouldn't know about that, because the return value of ioctlsocket (and all other system calls in internal_setblocking) is ignored. You might want to take a look at this KB article: http://support.microsoft.com/kb/179942/EN-US/ which claims that the WSA_FLAG_OVERLAPPED flag must be set on a socket on NT 4.0 for non-blocking mode to work. This shouldn't matter here, as the system is W2k, and because we used the socket API to create the socket (right?). Regards, Martin
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