Implement suspend() and resume() for OfflineAudioContext

third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp

Index: third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp
diff --git a/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp b/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp
index 393494ccdd760e81d9e8f4b3055fbb1ecb402934..c6e57ad6b0d8cf56b2c75b5881467343009225fd 100644
--- a/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp
+++ b/third_party/WebKit/Source/modules/webaudio/DeferredTaskHandler.cpp
@@ -60,6 +60,13 @@ void DeferredTaskHandler::unlock()
     m_contextGraphMutex.unlock();
 }
 
+void DeferredTaskHandler::offlineLock()
+{
+    // It is safe to lock the audio thread for offline rendering.
+    ASSERT(isAudioThread());

[Raymond Toy, 2015/10/16 23:32:36]

What should we do in a release build if we accidentally do call this from the
audio thread?  It seems pretty bad if this is called from the audio thread.

[hongchan, 2015/10/19 20:08:12]

This is why I completely separated the render method for the offline audio
context. So there is no possibility this method gets called by the realtime
context. However, I can agree with your concern.

We can always use tryLock() if the current thread is not audio thread. WDYT?

[Raymond Toy, 2015/10/19 20:27:27]

Maybe RELEASE_ASSERT or RELEASE_ASSERT_WITH_MESSAGE?

[hongchan, 2015/10/20 22:03:06]

Done.

+    m_contextGraphMutex.lock();
+}
+
 #if ENABLE(ASSERT)
 bool DeferredTaskHandler::isGraphOwner()
 {