PPAPI: Get TrackedCallback ready for running on non-main threads.

ppapi/proxy/file_chooser_resource.cc

Index: ppapi/proxy/file_chooser_resource.cc
diff --git a/ppapi/proxy/file_chooser_resource.cc b/ppapi/proxy/file_chooser_resource.cc
index 87d11285e1d1b1323370c53bf7ff14f34d849fdd..4333bfdbe9c485c47b4ce46ac026c9a7ada5b46e 100644
--- a/ppapi/proxy/file_chooser_resource.cc
+++ b/ppapi/proxy/file_chooser_resource.cc
@@ -126,7 +126,7 @@ void FileChooserResource::OnPluginMsgShowReply(
   }
 
   // Notify the plugin of the new data.
-  TrackedCallback::ClearAndRun(&callback_, params.result());
+  callback_->Run(params.result());

[viettrungluu, 2012/09/25 00:18:11]

I don't see how you can leave the value of |callback_| in place in the face of
the usage of |TrackedCallback::IsPending(callback_);| -- am I missing something?

[dmichael (off chromium), 2012/10/24 21:40:52]

IsPending(callback_) will return false if:
callback_ is valid
AND
callback_ has not yet completed.

Since we're doing Run(), the callback will complete. The downside with this
approach is the callback will never really be destroyed until it's replaced or
its owning resource goes away. But that seems pretty harmless.

The reason we can't use ClearAndRun anymore is because Run will (in the next CL)
potentially post a task to run the Callback on a different thread (i.e., the
thread that initiated the request). So this situation could happen:
1) Plugin makes a request (e.g., to show a FileChooser), but makes the request
from a background thread (which has an associated PPB_MessageLoop_Dev where the
callback should run).
2) At some time later, a response message comes back on the main thread, and we
have to schedule the callback to run on the background thread.
Suppose that another request comes in from the background thread before the
callback has a chance to fire. If we did ClearAndRun, then callback_ would be
NULL, so it would look like there was no callback pending. The new request would
be allowed, even though we haven't completely finished servicing the previous
request.

This way, IsPending will still show that there's a pending callback until the
callback actually runs and is put in the "completed" state.

   // DANGER: May delete |this|!
 }