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

content/public/browser/render_process_host.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_PUBLIC_BROWSER_RENDER_PROCESS_HOST_H_
 #define CONTENT_PUBLIC_BROWSER_RENDER_PROCESS_HOST_H_
 
 #include "base/basictypes.h"
 #include "base/id_map.h"
 #include "base/process.h"
@@ skipping 162 matching lines @@
   // by listeners to register and unregister pending views to prevent the
   // process from exiting.
   virtual void AddPendingView() = 0;
   virtual void RemovePendingView() = 0;
 
   // Sets a flag indicating that the process can be abnormally terminated.
   virtual void SetSuddenTerminationAllowed(bool allowed) = 0;
   // 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
   // 10 milliseconds.
   virtual base::TimeDelta GetChildProcessIdleTime() const = 0;
 
   // Static management functions -----------------------------------------------
 
   // Flag to run the renderer in process.  This is primarily
   // for debugging purposes.  When running "in process", the
@@ skipping 36 matching lines @@
 
   // Returns the current max number of renderer processes used by the content
   // module.
   static size_t GetMaxRendererProcessCount();
 };
 
 }  // namespace content.
 
 #endif  // CONTENT_PUBLIC_BROWSER_RENDER_PROCESS_HOST_H_