Stop the AudioDeviceThread when the IO loop goes away.

content/renderer/media/audio_device.cc

Index: content/renderer/media/audio_device.cc
diff --git a/content/renderer/media/audio_device.cc b/content/renderer/media/audio_device.cc
index 3f89e93ced06d84d6e3524353648f45c4abe2a88..c4a10f04f4d09bb209e0c2c15e3cbf815a7b3c83 100644
--- a/content/renderer/media/audio_device.cc
+++ b/content/renderer/media/audio_device.cc
@@ -178,6 +178,11 @@ void AudioDevice::ShutDownOnIOThread() {
     stream_id_ = 0;
   }
 
+  // We can run into an issue where ShutDownOnIOThread is called right after
+  // OnStreamCreated is called in cases where Start/Stop are called before we
+  // get the OnStreamCreated callback.  To handle that corner case, we call
+  // Stop(). In most cases, the thread will already be stopped.
+  audio_thread_.Stop(MessageLoop::current());

[scherkus (not reviewing), 2012/02/29 21:10:15]

hold the phone...

combined with the change to WillDestroyCurrentMessageLoop() to synchronously
stop audio_thread_... perhaps we should always synchronously stop audio_thread_
inside of ShutDownOnIOThread()?

Here's my thinking... there are two spots where ShutDownOnIOThread can get
called:
  1) Stop() via PostTask
  2) WillDestroyCurrentMessageLoop()

In (1) we already call audio_thread_.Stop(MessageLoop::current()) prior to
posting the task for ShutDownOnIOThread(). If it doesn't matter which thread is
used to stop audio_thread_, then why not always stop it inside this method?
(hopefully I'm not missing anything here!)

If that all makes sense I wonder if audio_thread_.Stop() even needs to accept a
MessageLoop parameter anymore if synchronous stopping is always used.

[tommi (sloooow) - chröme, 2012/02/29 21:22:13]

We shouldn't do that on the IO thread due to thread restrictions.  However, when
we hit the WillDestroyCurrentMessageLoop case, that means that the Pipeline
thread is still running while the IO is ending and as we've seen in crash
reports, the main thread has also gone.  That's why I added the synchronous wait
there.  It would be good if the pipeline thread has been properly terminated
before the main and io threads go down.

   audio_callback_.reset();
 }
 
@@ -218,6 +223,7 @@ void AudioDevice::OnStreamCreated(
     return;
   }
 
+  DCHECK(audio_thread_.IsStopped());
   audio_callback_.reset(new AudioDevice::AudioThreadCallback(audio_parameters_,
       handle, length, callback_));
   audio_thread_.Start(audio_callback_.get(), socket_handle, "AudioDevice");
@@ -234,6 +240,8 @@ void AudioDevice::Send(IPC::Message* message) {
 }
 
 void AudioDevice::WillDestroyCurrentMessageLoop() {
+  LOG(ERROR) << "IO loop going away before the audio device has been stopped";
+  audio_thread_.Stop(NULL);
   ShutDownOnIOThread();
 }