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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
