[Python-Dev] test_timeout fails on Win98SE

[M.-A. Lemburg]

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