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
_______________________________________________
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
