Only wait for CancelAllRequests done if the post task succeeds

chrome/browser/history/android/sqlite_cursor.cc

Index: chrome/browser/history/android/sqlite_cursor.cc
diff --git a/chrome/browser/history/android/sqlite_cursor.cc b/chrome/browser/history/android/sqlite_cursor.cc
index 3a933c665afe21e89892dacd56b07fc7eccb0420..d337a468c8dfe86c6f572286eb8a270361ed38b3 100644
--- a/chrome/browser/history/android/sqlite_cursor.cc
+++ b/chrome/browser/history/android/sqlite_cursor.cc
@@ -156,12 +156,11 @@ SQLiteCursor::~SQLiteCursor() {
     CancelAllRequests(NULL);
   } else {
     base::WaitableEvent event(false, false);
-    BrowserThread::PostTask(
-        BrowserThread::UI,
-        FROM_HERE,
+    if (BrowserThread::PostTask(BrowserThread::UI, FROM_HERE,

[sky, 2013/05/30 19:33:05]

From PostTask: " even if the task is posted, there's no guarantee that it will
run, since the target thread may already have a Quit message in its queue."

Does this code need to deal with the case of the UI messageloop not running or
in the process of shutting down?

[michaelbai, 2013/05/31 05:17:02]

In the case of UI message loop goes away, the whole process will be destroyed
soon, we don't care about deleting objects.
The SQLitCursor(this pointer) could be destroy from UI thread, so I removed the
wait event, put cleanup code into DestroyOnUIThread, and hope it get chance to
run, the Java code will not wait the cursor be destroyed any more.

I also modified unit test to reflect this change.

On 2013/05/30 19:33:05, sky wrote:

         base::Bind(&SQLiteCursor::CancelAllRequests, base::Unretained(this),
-                   &event));
-    event.Wait();
+                   &event))) {
+      event.Wait();
+    }
   }
 
   BrowserThread::PostTask(