Revised r408 such that we no longer sometimes fail MetricsServiceTest.CrashRenderers.

That test showed that we were exiting the browser process without noticing that a child process had crashed.  I fixed that by simply adding a check to see if the child process is still around before initiating the normal close of the child process.  This corresponds to the case where the browser decides to close a renderer.

As a result, the race for the MessageLoop to receive a Task notifying the RenderProcessHost of a crashed renderer is removed from the picture.

The bulk of this CL is just re-landing r408, which jar reviewed.

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@498 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 2 insertions, 2 deletions

diff --git a/chrome/browser/plugin_process_host.cc b/chrome/browser/plugin_process_host.cc
index 7ee3015..f64af9d 100644
--- a/chrome/browser/plugin_process_host.cc
+++ b/chrome/browser/plugin_process_host.cc
@@ -329,7 +329,7 @@ PluginProcessHost::PluginProcessHost(PluginService* plugin_service)
 
 PluginProcessHost::~PluginProcessHost() {
   if (process_.handle()) {
-    MessageLoop::current()->WatchObject(process_.handle(), NULL);
+    watcher_.StopWatching();
     ProcessWatcher::EnsureProcessTerminated(process_.handle());
   }
 }
@@ -461,7 +461,7 @@ bool PluginProcessHost::Init(const std::wstring& dll,
     process_.set_handle(process);
   }
 
-  MessageLoop::current()->WatchObject(process_.handle(), this);
+  watcher_.StartWatching(process_.handle(), this);
 
   // Give all plugins "background" priority.  See http://b/issue?id=1280317.
   process_.SetProcessBackgrounded(true);