[Python-Dev] Who understands _ssl.c on Windows? (original) (raw)

Tim Peters tim.peters at gmail.com
Sun Apr 9 06:49:18 CEST 2006

So Martin fixed _ssl.c on Windows (thanks! what a subtle pit that turned out to be), and I restored the test_timeout() test in test_socket_ssl. That test was introduced on Bug Day, but:

a) First got fiddled to exclude Windows, because the _ssl.c bug made it impossible for the test to pass on Windows; and,

b) Then got disabled on all boxes, because the gmail.org address it tried to connect to stopped responding to anyone, and all buildbot test runs on all non-Windows boxes failed as a result for hours that day.

We have one oddity remaining: now that test fails on, and only on, Trent's "x86 W2k trunk" buildbot. It always times out there, and never times out elsewhere. It times out during a socket.connect() call on that buildbot. The socket timeout is set to 30 seconds (seems a very long time, right?).

Trent (and anyone else who wants to play along), what happens if you do this by hand in a current trunk or 2.4 build?:

import socket s = socket.socket() s.settimeout(30.0) s.connect(("gmail.org", 995))

On my box (when gmail.org:995 responds at all), the connect succeeds in approximately 0.03 seconds, giving 29.97 seconds to spare ;-)

Can you identify a reason for why it times out on the Win2K buildbot? (beats me -- firewall issue, DNS sloth, ...?)

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:

import socket s = socket.socket() s.settimeout(0.01) s.connect(("gmail.org", 995)) Traceback (most recent call last): File "", line 1, in File "", line 1, in connect socket.timeout: timed out

More information about the Python-Dev mailing list