Bug 1135785 - Make MediaTaskQueue::IsCurrentThreadIn actually do the right thing on release builds. r=cpearce
authorBobby Holley <bobbyholley@gmail.com>
Mon, 23 Feb 2015 17:46:55 -0800
changeset 261585 e637962ba64b4a6dc25965d9179af92c30200815
parent 261584 dc0b58714ffc7c5865bd16e102b61ca91da2fb51
child 261586 2a077477b16c970ce100f41fbba2dde13fc9919d
push id830
push userraliiev@mozilla.com
push dateFri, 19 Jun 2015 19:24:37 +0000
treeherdermozilla-release@932614382a68 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerscpearce
bugs1135785, 968016
milestone39.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1135785 - Make MediaTaskQueue::IsCurrentThreadIn actually do the right thing on release builds. r=cpearce The current situation is really dangerous because it compiles on release builds, but just lies. This bit me when I tried to use it for non-assertion purposes. My reading of the reasoning for the current setup in bug 968016 is that we didn't trust nsIEventTarget::IsCurrentThreadOn or thought it might be slow. But the implementation of MediaTaskQueue::IsCurrentThreadIn doesn't actually use that, and indeed currently does all of the work for this feature in release builds anyway.
dom/media/MediaTaskQueue.cpp
--- a/dom/media/MediaTaskQueue.cpp
+++ b/dom/media/MediaTaskQueue.cpp
@@ -190,22 +190,18 @@ MediaTaskQueue::IsEmpty()
 {
   MonitorAutoLock mon(mQueueMonitor);
   return mTasks.empty();
 }
 
 bool
 MediaTaskQueue::IsCurrentThreadIn()
 {
-#ifdef DEBUG
   MonitorAutoLock mon(mQueueMonitor);
   return NS_GetCurrentThread() == mRunningThread;
-#else
-  return false;
-#endif
 }
 
 nsresult
 MediaTaskQueue::Runner::Run()
 {
   RefPtr<nsIRunnable> event;
   {
     MonitorAutoLock mon(mQueue->mQueueMonitor);