Implement suspend() and resume() for OfflineAudioContext

Source/modules/webaudio/DeferredTaskHandler.cpp

 /*
  * Copyright (C) 2010, Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1.  Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2.  Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 24 matching lines @@
 
 namespace blink {
 
 void DeferredTaskHandler::lock()
 {
     // Don't allow regular lock in real-time audio thread.
     ASSERT(isMainThread());
     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
     // - it should use regular lock.
     ASSERT(isAudioThread());
     if (!isAudioThread()) {
         // In release build treat tryLock() as lock() (since above
         // ASSERT(isAudioThread) never fires) - this is the best we can do.
         lock();
         return true;
@@ skipping 212 matching lines @@
 {
     ASSERT(isMainThread());
     AutoLocker locker(*this);
     m_renderingOrphanHandlers.clear();
     m_deletableOrphanHandlers.clear();
 }
 
 } // namespace blink
 
 #endif // ENABLE(WEB_AUDIO)