Support using TrackedCallbacks as hints to determine the handling thread of resource reply messages

ppapi/proxy/plugin_globals.h

Index: ppapi/proxy/plugin_globals.h
diff --git a/ppapi/proxy/plugin_globals.h b/ppapi/proxy/plugin_globals.h
index bc55245d611a10c5dc154529a1749b595ef86134..029e2d2e28eebae94a1d69040ea59a19d04221f7 100644
--- a/ppapi/proxy/plugin_globals.h
+++ b/ppapi/proxy/plugin_globals.h
@@ -34,6 +34,7 @@ namespace proxy {
 
 class MessageLoopResource;
 class PluginProxyDelegate;
+class ResourceReplyThreadRegistrar;
 
 class PPAPI_PROXY_EXPORT PluginGlobals : public PpapiGlobals {
  public:
@@ -128,6 +129,10 @@ class PPAPI_PROXY_EXPORT PluginGlobals : public PpapiGlobals {
   // The embedder should call this function when the command line is known.
   void set_command_line(const std::string& c) { command_line_ = c; }
 
+  ResourceReplyThreadRegistrar* resource_reply_thread_registrar() {
+    return resource_reply_thread_registrar_.get();
+  }
+
  private:
   class BrowserSender;
 
@@ -160,6 +165,8 @@ class PPAPI_PROXY_EXPORT PluginGlobals : public PpapiGlobals {
   // lazily, since it might not be needed.
   scoped_ptr<base::Thread> file_thread_;
 
+  scoped_refptr<ResourceReplyThreadRegistrar> resource_reply_thread_registrar_;

[dmichael (off chromium), 2013/12/10 23:38:01]

Is there any reason to not just hold it by value?

[yzshen1, 2013/12/11 00:21:49]

Mostly because the resources and the message filter on the IO thread will hold
pointers to this object.

We could make it owned by this class if we make sure this object outlive:
- all resources
- the channel on the IO thread

I could double check and make it non-ref-counted. I was just a little bit
concerned about adding an implicit constraint that this object must outlive the
message filter on the IO thread. But maybe it is okay because we are already
passing non-ref-counted pointer of the instance set to the message filter.

What do you think?

[dmichael (off chromium), 2013/12/11 21:30:36]

Hmm, yeah... it's a little unclear to me what the lifetimes are.

PluginDelegate already assumes that PluginGlobals outlives it
(PluginDelegate::delegate_ is the PpapiThread, which owns PluginGlobals).
Similarly, PluginDelegate's lifetime is scoped to its channel. It appears to be
deleted only in OnChannelError:
https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/proxy/plugin...
...
And during shutdown, it will clear the channel...  which will (inside of
IPC::ChannelProxy) post a task to the IO thread to delete the MessageFilter...

So I guess at shutdown it might actually be possible that the
PluginMessageFilter does outlive PluginGlobals.

Okay, I guess we have to do it that way.

[yzshen1, 2013/12/11 22:22:07]

Yeah, in ChildProcess, the main_thread_ member (in our case ppapi_thread) is
destroyed before io_thread_. Therefore it is possible that PluginGlobals is gone
while the IO thread is still processing messages.

(That makes me think that we should probably also change
globally_seen_instance_ids_ to be ref-counted.)

+
   DISALLOW_COPY_AND_ASSIGN(PluginGlobals);
 };