PPAPI: Blocking callbacks shouldn't need a target_loop_

ppapi/shared_impl/tracked_callback.cc

Index: ppapi/shared_impl/tracked_callback.cc
diff --git a/ppapi/shared_impl/tracked_callback.cc b/ppapi/shared_impl/tracked_callback.cc
index 1a3ac21adb5610b332f617b3c10b13f1ec74acf2..f7192df3c450782d4adc6b3fa9368c49e87caa67 100644
--- a/ppapi/shared_impl/tracked_callback.cc
+++ b/ppapi/shared_impl/tracked_callback.cc
@@ -167,7 +167,11 @@ void TrackedCallback::PostRun(int32_t result) {
 
   base::Closure callback_closure(
       RunWhileLocked(base::Bind(&TrackedCallback::Run, this, result)));
-  if (!target_loop_.get()) {
+  if (is_blocking()) {
+    // We might not have a MessageLoop to post to, so we must call Run()
+    // directly.
+    callback_closure.Run();
+  } else if (!target_loop_.get()) {

[bbudge, 2013/09/04 22:29:19]

It seems like the most common case is last. Do you have a feel for the
likelihood of the different cases? Did you consider switching the ifs? In other
words,

if (target_loop_.get()) {
....post task to target_loop_
} else {
  if (is_blocking()) {
.....blocking code
  } else {
.....in-process code
  }
}

     // We must be running in-process and on the main thread (the Enter
     // classes protect against having a null target_loop_ otherwise).
     DCHECK(IsMainThread());