NealN very recently changed test_timeout so that it actually ran its tests (it didn't before, unless it was run directly "by hand"). The result here on Win98SE: test test_timeout failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_timeout.py", line 107, in testConnectTimeout self.addr_remote) File "C:\CODE\PYTHON\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: error 1 test failed: test_timeout Doing what the test does by hand doesn't raise an exception either:
import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(.001) sock.connect(('www.google.com', 80))
I suspect (but don't know) that Win98SE treats .001 as if it were some larger value. It would help if I could find an address that doesn't get connected instantly from here <0.7 wink>.
-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org] On Behalf Of Tim Peters Sent: Tuesday, February 18, 2003 5:38 PM To: PythonDev Subject: [Python-Dev] test_timeout fails on Win98SE
I suspect (but don't know) that Win98SE treats .001 as if it were some larger value. It would help if I could find an address that doesn't get connected instantly from here <0.7 wink>.
I don't know if it's related, but Win98's lowest clock resolution is 55ms. It's 10ms in NT. I don't have a 98 install to see if 0.006 will succeed or still fail though.
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 ...
Tim Peters wrote:
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 ...
MS isn't sure about this either... http://lists.w3.org/Archives/Public/www-lib/2000AprJun/0125.html What I don't understand is why an error is set when you are in fact properly connected. Looks like Guido knows the answer: http://mail.python.org/pipermail/zodb-checkins/2002-September/002669.html -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 19 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 41 days left EuroPython 2003, Charleroi, Belgium: 125 days left
Looks like Guido knows the answer: http://mail.python.org/pipermail/zodb-checkins/2002-September/002669.html
But somehow that doesn't work either. I recall a MS page about this that recommended not trying a second connect() but calling select() to determine whether the socket is writable (== connected). I've now implemented that (in the Windows version of the code only). The test_timeout.py now works for me on Win98 (most of the time) and on Win2k (all the time except the one time when ZoneAlarm interfered :-). I consider this closed now. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Guido van Rossum -
logistix -
M.-A. Lemburg -
Tim Peters