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

ppapi/proxy/file_chooser_resource.cc

 // 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.
 
 #include "ppapi/proxy/file_chooser_resource.h"
 
 #include "base/string_split.h"
 #include "ipc/ipc_message.h"
 #include "ppapi/c/pp_errors.h"
 #include "ppapi/proxy/dispatch_reply_message.h"
@@ skipping 108 matching lines @@
     // Convert each of the passed in file infos to resources. These will be
     // owned by the FileChooser object until they're passed to the plugin.
     DCHECK(file_queue_.empty());
     for (size_t i = 0; i < chosen_files.size(); i++) {
       file_queue_.push(PPB_FileRef_Proxy::DeserializeFileRef(
           chosen_files[i]));
     }
   }
 
   // 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|!
 }
 
 int32_t FileChooserResource::ShowInternal(
     PP_Bool save_as,
     const PP_Var& suggested_file_name,
     scoped_refptr<TrackedCallback> callback) {
   if (TrackedCallback::IsPending(callback_))
     return PP_ERROR_INPROGRESS;
 
   if (!sent_create_to_renderer())
     SendCreateToRenderer(PpapiHostMsg_FileChooser_Create());
 
   callback_ = callback;
   StringVar* sugg_str = StringVar::FromPPVar(suggested_file_name);
 
   CallRenderer(PpapiHostMsg_FileChooser_Show(
       PP_ToBool(save_as),
       mode_ == PP_FILECHOOSERMODE_OPENMULTIPLE,
       sugg_str ? sugg_str->value() : std::string(),
       accept_types_));
   return PP_OK_COMPLETIONPENDING;
 }
 
 }  // namespace proxy
 }  // namespace ppapi