[Python-Dev] OK to lower timeout for test_timeout's testConnectTimeout test? (original) (raw)

Tim Peters tim.peters at gmail.com
Fri Aug 6 00:31:49 CEST 2004

[Brett Cannon]

I am actually getting failures from testtimeout's testConnectTimeout

It would have helped if you had been specific about the failures you're seeing, and whether you get them all the time, or just some of the time.

since the Net connection I have at school lets me connect to Google in under the .001 connection timeout value. If I push it to .00000001 (a hundred-millionth of a second) it then fails consistently.

What fails? The test fails? The socket fails to connect?

Note that .0000001 is the same as passing, e.g., 1e-200. select() only accepts arguments at microsecond granularity, so any positive non-zero timeout value < 1e-6 gets chopped to exactly 0.0.

tv.tv_sec = (int)s->sock_timeout;
tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6);

The test really doesn't intend to pass a timeout of exactly 0 to select(), so we can't change this to less than 1e-6.

Now the problem is that the second part of the test uses this and a fuzz value (currently at 2) to see if the test timed out within the proper amount of time. The comparison is basically if the amount of time it took to do the timed out failure is less than timeout + fuzz. So lowering this number could possibly affect the test, although at .001 seconds, I am doubting that will occur. But since these types of timing tests can be touchy I thought I would double-check.

Na, 2.0 is gigantic compared to .001 already. For the purposes of the test, 2 isn't really more gigantic compared to 1e-6.

So if anyone thinks it is bad to lower the value to .00000001 then please let me know.

Changing it to 1e-7 is out, for the reason explained earlier. I'd like to keep .001, because while the interface to select() allows specifying microsecond resolution, there's no guarantee that it can use that much precision. Most (all?) implementations should be able to deal with millisecond resolution, though. Perhaps we could pick on something other than www.google.com. Maybe www.python.org (everyone in America is far from that ).

More information about the Python-Dev mailing list