This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt
Date 2013-08-03.10:22:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM30qe__hx5LEbzpD6XHpYcCy0Z5XbExUtCwXbYEJtCm3Q@mail.gmail.com>
In-reply-to <1375503696.67.0.390887159285.issue16853@psf.upfronthosting.co.za>
Content
> Guido van Rossum added the comment:
> Can you try again with the failing assert replaced with this?
>
> 	self.assertTrue(0.018 <= t2-t0 <= 0.028, t2-t0)
>
> That should be a better way to check that code works.

I'm still getting - less frequent - failures:
"""
======================================================================
FAIL: test_run_until_complete_timeout (events_test.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/events_test.py", line 194, in test_run_until_complete_timeout
    self.assertTrue(0.018 <= t2-t0 <= 0.028, t2-t0)
AssertionError: False is not true : 0.029771103999337356

----------------------------------------------------------------------
"""

Looking at strace output:
11:00:47.383145 select(4, [3], [], [], {0, 9765}) = 0 (Timeout) <0.015713>

select() takes an extra 5ms (15ms instead of 10ms).

5ms is quite low for a GPOS (the typical quantum is around 4ms for
250Hz timer, and on my machine I have high-resolution timers
configured but probably a crappy hardware).

I'd suggest increasing the timeouts (especially when Tulip gets
merged, it'll likely fail on many buildbots).
History
Date User Action Args
2013-08-03 10:22:39neologixsetrecipients: + neologix, gvanrossum, pitrou, giampaolo.rodola, christian.heimes, meador.inge, rosslagerwall, sbt, felipecruz
2013-08-03 10:22:39neologixlinkissue16853 messages
2013-08-03 10:22:39neologixcreate