Simplify threading in browser thread by making only ChromeThread deal with di...

chrome/browser/renderer_host/resource_message_filter.cc

Index: chrome/browser/renderer_host/resource_message_filter.cc
===================================================================
--- chrome/browser/renderer_host/resource_message_filter.cc	(revision 30037)
+++ chrome/browser/renderer_host/resource_message_filter.cc	(working copy)
@@ -550,7 +550,8 @@
   // file thread.  We need this object to be destructed on the IO thread, so do
   // the refcounting manually.
   AddRef();
-  ChromeThread::GetMessageLoop(ChromeThread::FILE)->PostTask(FROM_HERE,
+  ChromeThread::PostTask(
+      ChromeThread::FILE, FROM_HERE,
       NewRunnableFunction(&ResourceMessageFilter::OnGetPluginsOnFileThread,
           this, refresh, reply_msg));
 }
@@ -561,20 +562,9 @@
     IPC::Message* reply_msg) {
   std::vector<WebPluginInfo> plugins;
   NPAPI::PluginList::Singleton()->GetPlugins(refresh, &plugins);
-
   ViewHostMsg_GetPlugins::WriteReplyParams(reply_msg, plugins);
-  // Note, we want to get to the IO thread now, but the file thread outlives it
-  // so we can't post a task to it directly as it might be in the middle of
-  // destruction.  So hop through the main thread, where the destruction of the
-  // IO thread happens and hence no race conditions exist.
-  filter->ui_loop()->PostTask(FROM_HERE,
-      NewRunnableFunction(&ResourceMessageFilter::OnNotifyPluginsLoaded,
-          filter, reply_msg));
-}
-
-void ResourceMessageFilter::OnNotifyPluginsLoaded(ResourceMessageFilter* filter,
-                                                  IPC::Message* reply_msg) {
-  ChromeThread::GetMessageLoop(ChromeThread::IO)->PostTask(FROM_HERE,
+  ChromeThread::PostTask(
+      ChromeThread::IO, FROM_HERE,
       NewRunnableMethod(filter, &ResourceMessageFilter::OnPluginsLoaded,
           reply_msg));
 }