Implement suspend() and resume() for OfflineAudioContext

Source/modules/webaudio/DeferredTaskHandler.cpp

Index: Source/modules/webaudio/DeferredTaskHandler.cpp
diff --git a/Source/modules/webaudio/DeferredTaskHandler.cpp b/Source/modules/webaudio/DeferredTaskHandler.cpp
index c2605c157caa2787a5da09895322d8aa52a7ff66..7b635016c2b10687d0001547dd8a9bc2428aaf6b 100644
--- a/Source/modules/webaudio/DeferredTaskHandler.cpp
+++ b/Source/modules/webaudio/DeferredTaskHandler.cpp
@@ -42,6 +42,19 @@ void DeferredTaskHandler::lock()
     m_contextGraphMutex.lock();
 }
 
+void DeferredTaskHandler::forceLock()
+{
+    // This allows the regular lock in non-real-time audio thread.

[Raymond Toy, 2015/06/16 17:57:09]

I think this can only be used with an online context.  Is there any way we can
check or assert that?  If not, add comment saying this can only be used for an
offline context.

[hongchan, 2015/06/16 21:31:21]

No. This lock is only for offline audio context. My comment about the
'non-real-time' audio thread seems to be clear enough.

[Raymond Toy, 2015/06/16 21:46:38]

Typo on my part. I meant offline.  I think since it's called offline, replacing
"non-real-time" to "offline" makes it clearer.  The thread name itself says
"offline", not "non-real-time"

+    ASSERT(!isMainThread());
+    if (isMainThread()) {

[Raymond Toy, 2015/06/16 17:57:09]

This is confusing.  You ASSERT that it's not the main thread and then test that
it is. I'd invert the if condition if possible.

[hongchan, 2015/06/16 21:31:20]

I though we discussed this: for debug build, the assertion will fail if this
gets called from the main thread. However, if that happens in the release build,
we can't crash the browser. So we just do the best thing we can do - tryLock().

I just followed the logic of tryLock and inverted it.

[Raymond Toy, 2015/06/16 21:46:38]

As we discussed offline, this is ok.  But now I wonder if the main thread needs
to do a tryLock.  The main thread is allowed to block, so why not just grab the
lock anyway?

+        // If this gets called in the main thread, do tryLock() instead.
+        m_contextGraphMutex.tryLock();
+        return;
+    }
+
+    m_contextGraphMutex.lock();
+}
+
 bool DeferredTaskHandler::tryLock()
 {
     // Try to catch cases of using try lock on main thread