Revert of Improving the fake clock and using it to fix a flaky STUN timeout test. (patchset #10 id:180001 of https://codereview.webrtc.org/2024813004/ )
Reason for revert: There seems to be a TSan warning that wasn't caught by the trybot: https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/6732/steps/peerconnection_unittests/logs/stdio Apparently a thread is still alive even after destroying WebRTCSession. Need to think of a way to fix this, without adding a critical section around g_clock (since that would hurt performance). Original issue's description: > Improving the fake clock and using it to fix a flaky STUN timeout test. > > When the fake clock's time is advanced, it now ensures all pending > queued messages have been dispatched. This allows us to write a > "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up > until the target time. > > Useful in this case, where we know the STUN timeout should take a total > of 9500ms, but it would be overly complex to write test code that waits > for each individual timeout, ensures a STUN packet has been > retransmited, etc. > > (The test described above *should* be written, but it belongs in > p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc). > > Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a > Cr-Commit-Position: refs/heads/master@{#13043} TBR=pthatcher@webrtc.org,tommi@webrtc.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.webrtc.org/2038213002 Cr-Commit-Position: refs/heads/master@{#13045}
This commit is contained in:
@ -301,7 +301,7 @@ TEST(TimeDelta, NumericOperators) {
|
||||
// fake clock when it's set.
|
||||
TEST(FakeClock, TimeFunctionsUseFakeClock) {
|
||||
FakeClock clock;
|
||||
SetClockForTesting(&clock);
|
||||
SetClock(&clock);
|
||||
|
||||
clock.SetTimeNanos(987654321u);
|
||||
EXPECT_EQ(987u, Time32());
|
||||
@ -310,7 +310,7 @@ TEST(FakeClock, TimeFunctionsUseFakeClock) {
|
||||
EXPECT_EQ(987654321u, TimeNanos());
|
||||
EXPECT_EQ(1000u, TimeAfter(13));
|
||||
|
||||
SetClockForTesting(nullptr);
|
||||
SetClock(nullptr);
|
||||
// After it's unset, we should get a normal time.
|
||||
EXPECT_NE(987, TimeMillis());
|
||||
}
|
||||
@ -348,7 +348,7 @@ TEST(FakeClock, SettingTimeWakesThreads) {
|
||||
int64_t real_start_time_ms = TimeMillis();
|
||||
|
||||
FakeClock clock;
|
||||
SetClockForTesting(&clock);
|
||||
SetClock(&clock);
|
||||
|
||||
Thread worker;
|
||||
worker.Start();
|
||||
@ -359,25 +359,24 @@ TEST(FakeClock, SettingTimeWakesThreads) {
|
||||
message_handler_dispatched.Set();
|
||||
};
|
||||
FunctorMessageHandler<void, decltype(functor)> handler(functor);
|
||||
worker.PostDelayed(60000, &handler);
|
||||
worker.PostDelayed(10000, &handler);
|
||||
|
||||
// Wait for a bit for the worker thread to be started and enter its socket
|
||||
// select(). Otherwise this test would be trivial since the worker thread
|
||||
// would process the event as soon as it was started.
|
||||
// select().
|
||||
Thread::Current()->SleepMs(1000);
|
||||
|
||||
// Advance the fake clock, expecting the worker thread to wake up
|
||||
// and dispatch the message instantly.
|
||||
clock.AdvanceTime(TimeDelta::FromSeconds(60u));
|
||||
EXPECT_TRUE(message_handler_dispatched.Wait(0));
|
||||
// and dispatch the message quickly.
|
||||
clock.AdvanceTime(TimeDelta::FromSeconds(10u));
|
||||
message_handler_dispatched.Wait(Event::kForever);
|
||||
worker.Stop();
|
||||
|
||||
SetClockForTesting(nullptr);
|
||||
SetClock(nullptr);
|
||||
|
||||
// The message should have been dispatched long before the 60 seconds fully
|
||||
// elapsed (just a sanity check).
|
||||
// The message should have been dispatched long before the 10 seconds fully
|
||||
// elapsed.
|
||||
int64_t real_end_time_ms = TimeMillis();
|
||||
EXPECT_LT(real_end_time_ms - real_start_time_ms, 10000);
|
||||
EXPECT_LT(real_end_time_ms - real_start_time_ms, 2000);
|
||||
}
|
||||
|
||||
} // namespace rtc
|
||||
|
||||
Reference in New Issue
Block a user