From 6b1753827c4f458b55eae64bfa0f8a699ebcee4c Mon Sep 17 00:00:00 2001 From: "markus@chromium.org" Date: Tue, 13 Oct 2009 06:47:47 +0000 Subject: This is a second attempt at submitting this changelist. The original one was http://codereview.chromium.org/196053 It turns out, since none of our tests abstract time correctly, unittests are very sensitive to subtle changes in timing. This made some of the valgrind tests on Linux fail, and unfortunately, neither my desktop nor the trybots could reproduce the problem reliably. As far as I can tell, all the (design) bugs are in the unittests. The browser is actually fine. Tweaked the code a little more. Will resubmit and carefully monitor the buildbots. Original change description follows: When converting between units of time or data types of different precision, we have to be careful to consistently round in the same direction. Timeout checks usually check if Now() is less or equal to a deadline in order to determine if a timeout has occurred. This correctly handles the case where actual sleep times are equal or longer than requested sleep times. But if we round down when setting the sleep delay, this can result in unnecessary and expensive looping. Make sure, we always round up when converting to a format with less precision. BUG=none TEST=none Review URL: http://codereview.chromium.org/257044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28801 0039d316-1c4b-4281-b951-d872f2087c98 --- net/socket/socket_test_util.cc | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'net/socket/socket_test_util.cc') diff --git a/net/socket/socket_test_util.cc b/net/socket/socket_test_util.cc index e053f6c..60ef70c 100644 --- a/net/socket/socket_test_util.cc +++ b/net/socket/socket_test_util.cc @@ -334,6 +334,15 @@ void ClientSocketPoolTest::SetUp() { void ClientSocketPoolTest::TearDown() { // The tests often call Reset() on handles at the end which may post // DoReleaseSocket() tasks. + // Pending tasks created by client_socket_pool_base_unittest.cc are + // posted two milliseconds into the future and thus won't become + // scheduled until that time. + // We wait a few milliseconds to make sure that all such future tasks + // are ready to run, before calling RunAllPending(). This will work + // correctly even if Sleep() finishes late (and it should never finish + // early), as all we have to ensure is that actual wall-time has progressed + // past the scheduled starting time of the pending task. + PlatformThread::Sleep(10); MessageLoop::current()->RunAllPending(); } -- cgit v1.1