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

[Brett C.]

Tim Peters wrote:

> [Brett Cannon]
> 
>>I am actually getting failures from test_timeout'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.
> 

Sorry about that; almost filed a bug report and pasted it in there; just 
plain forgot to paste into here:

======================================================================
FAIL: testConnectTimeout (__main__.TimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/test/test_timeout.py", line 116, in testConnectTimeout
     self.addr_remote)
AssertionError: error not raised

----------------------------------------------------------------------

And it always fails.

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

The test.  No connection error is reported.

> Note that .0000001 is the same as passing, e.g., 1e-200.

I actually meant 1e-08, but apparently that is a moot point.

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

That's weird because if I do the test with sock.settimeout(0.0) and then 
sock.connect(('www.google.com', 80)) I get::

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<string>", line 1, in connect
socket.error: (36, 'Operation now in progress')

But if I do the exact same thing (new socket, etc.) after closing the 
previous one but with sock.settimeout(0.00000001) I get::

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<string>", line 1, in connect
socket.timeout: timed out

which is what the test expects.  Could this be a platform difference? 
Or is the conversion happening else where and thus not the equivalent of 
passing 0 to settimeout()?

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

I figured as much.

> 
>>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 <wink>).

=)  I like that idea of changing of the site we hit.  Seems slightly 
rude to be eating Google's bandwidth with our regression suite when we 
have our own server we can pound (relatively speaking; obviously the 
test suite is not run by *that* many people).  I will go ahead and do that.

-Brett