From dde8d36fb09ab1e5d94fb8f3b6552624337084c0 Mon Sep 17 00:00:00 2001 From: "Byron Campen [:bwc]" Date: Tue, 28 Jul 2015 10:10:54 -0500 Subject: [PATCH] Bug 1059572 - Part 2: Make absolutely sure a timer is removed before reinitting it. r=nfroyd --- xpcom/threads/nsTimerImpl.cpp | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/xpcom/threads/nsTimerImpl.cpp b/xpcom/threads/nsTimerImpl.cpp index bd6fbc5dc3e..1cb8c165326 100644 --- a/xpcom/threads/nsTimerImpl.cpp +++ b/xpcom/threads/nsTimerImpl.cpp @@ -205,23 +205,7 @@ nsTimerImpl::InitCommon(uint32_t aType, uint32_t aDelay) return rv; } - /** - * In case of re-Init, both with and without a preceding Cancel, clear the - * mCanceled flag and assign a new mGeneration. But first, remove any armed - * timer from the timer thread's list. - * - * If we are racing with the timer thread to remove this timer and we lose, - * the RemoveTimer call made here will fail to find this timer in the timer - * thread's list, and will return false harmlessly. We test mArmed here to - * avoid the small overhead in RemoveTimer of locking the timer thread and - * checking its list for this timer. It's safe to test mArmed even though - * it might be cleared on another thread in the next cycle (or even already - * be cleared by another CPU whose store hasn't reached our CPU's cache), - * because RemoveTimer is idempotent. - */ - if (mArmed) { - gThread->RemoveTimer(this); - } + gThread->RemoveTimer(this); mCanceled = false; mTimeout = TimeStamp(); mGeneration = gGenerator++;