Safe and reliable fix for 2 race conditions.

content/renderer/media/audio_device.cc

Index: content/renderer/media/audio_device.cc
===================================================================
--- content/renderer/media/audio_device.cc	(revision 116480)
+++ content/renderer/media/audio_device.cc	(working copy)
@@ -108,11 +108,6 @@
 
 void AudioDevice::Stop() {
   DCHECK(MessageLoop::current() != ChildProcess::current()->io_message_loop());
-  // Max waiting time for Stop() to complete. If this time limit is passed,
-  // we will stop waiting and return false. It ensures that Stop() can't block
-  // the calling thread forever.
-  const base::TimeDelta kMaxTimeOut = base::TimeDelta::FromMilliseconds(1000);
-
   base::WaitableEvent completion(false, false);
 
   ChildProcess::current()->io_message_loop()->PostTask(
@@ -122,9 +117,7 @@
   // We wait here for the IO task to be completed to remove race conflicts
   // with OnLowLatencyCreated() and to ensure that Stop() acts as a synchronous
   // function call.
-  if (!completion.TimedWait(kMaxTimeOut)) {
-    LOG(ERROR) << "Failed to shut down audio output on IO thread";
-  }
+  completion.Wait();

[Chris Rogers, 2012/01/06 18:26:28]

Is there a case where the time-out is actually needed?  Shijing put that in
there, so we need his opinion about it.  As an alternative to this, we could
move the "completion" variable into a member variable instead of stack-based to
avoid it going away when this method finished.

[tommi (sloooow) - chröme, 2012/01/12 13:13:07]

What about moving the call to ShutDownAudioThread to be the last step inside
ShutDownOnIOThread?  That way we don't need the completion event at all.

This is assuming that the caller of Stop doesn't expect everything to be fully
stopped when Stop() returns.

   ShutDownAudioThread();
 }