Fixing a problem, where a hung renderer process is not killed when navigating away

content/public/browser/render_process_host.h

Index: content/public/browser/render_process_host.h
diff --git a/content/public/browser/render_process_host.h b/content/public/browser/render_process_host.h
index 189ede627c20b9e1640592d658e5b7160bf4802c..34f45694d8bffb2aa39383a03c6912b45e55a8a0 100644
--- a/content/public/browser/render_process_host.h
+++ b/content/public/browser/render_process_host.h
@@ -180,6 +180,10 @@ class CONTENT_EXPORT RenderProcessHost : public IPC::Message::Sender,
   // Returns true if the process can be abnormally terminated.
   virtual bool SuddenTerminationAllowed() const = 0;
 
+  // Returns true if the process can be killed if it is unresponsive. This will
+  // only be the case if there is only one view using this renderer process.
+  virtual bool TerminateOnUnresponsiveAllowed() const = 0;

[jam, 2012/03/02 00:21:10]

i dont think this new method is necessary? can't the caller just check
ListenersIterator() itself?

[nasko, 2012/03/02 18:40:36]

They probably could, but this means that they should be aware of the fact that
listeners are equivalent to views using the host (could be apparent, but it
wasn't to me).
If you believe that we shouldn't be exposing such a function, I can change the
code to iterate through the listeners to get a count, but that makes it harder
for potential future changes.

[Charlie Reis, 2012/03/02 19:17:02]

I agree with Nasko.  It's not clear to users of this class that listeners_
happens to be equivalent to the set of views being displayed by the process.  We
might attach other types of IPC::Channel::Listeners in the future, and callers
of this method should be shielded from that.

[jam, 2012/03/06 17:25:26]

There's a cost every time we add a method to a public API in terms of adding to
the list of methods that someone not familiar with content has to figure out.
We've tried really hard to keep the public API to a minimum.

In this particular case, chrome already has a number of places that make this
assumption and even iterate through them through ListenersIterator() and cast to
RenderWidgetHost.

[nasko, 2012/03/06 18:16:25]

The reason I picked the function is that the only real code I could see using
the iterators was the memory details code, which has big warning about the
usage.

I've changed it to use the iterator.

+
   // Returns how long the child has been idle. The definition of idle
   // depends on when a derived class calls mark_child_process_activity_time().
   // This is a rough indicator and its resolution should not be better than