[Python-Dev] Who understands _ssl.c on Windows?

[Tim Peters]

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 "<stdin>", line 1, in <module>
  File "<string>", line 1, in connect
socket.timeout: timed out