Implementation of PostTaskAndReply() in MessageLoopProxy and BrowserThread.

base/task.cc

Index: base/task.cc
diff --git a/base/task.cc b/base/task.cc
index 8c614734863fb5c8e34959dd2b00b4ac8c80e538..a6b674e55558e93100a640e561ce7223a2d2e5e0 100644
--- a/base/task.cc
+++ b/base/task.cc
@@ -4,6 +4,9 @@
 
 #include "base/task.h"
 
+#include "base/bind.h"
+#include "base/message_loop_proxy.h"
+
 Task::Task() {
 }
 
@@ -63,4 +66,38 @@ bool TaskClosureAdapter::kTaskLeakingDefault = false;
 
 }  // namespace subtle
 
+namespace internal {
+
+PostTaskAndReplyRelay::PostTaskAndReplyRelay(
+    const tracked_objects::Location& from_here,
+    const Closure& task,
+    const Closure& reply)
+    : from_here_(from_here),
+      origin_loop_(MessageLoopProxy::CreateForCurrentThread()) {
+  task_ = task;
+  reply_ = reply;
+}
+
+PostTaskAndReplyRelay::~PostTaskAndReplyRelay() {
+  DCHECK(origin_loop_->BelongsToCurrentThread());
+}
+
+void PostTaskAndReplyRelay::Run() {
+  task_.Run();
+  origin_loop_->PostTask(
+      from_here_,
+      Bind(&PostTaskAndReplyRelay::RunReplyAndSelfDestruct,
+           base::Unretained(this)));
+}
+
+void PostTaskAndReplyRelay::RunReplyAndSelfDestruct() {

[willchan no longer on Chromium, 2011/08/16 02:00:12]

Should |task_| be set to NULL at this point, which would free any bound
parameters? I also note that due to the member ordering, task_'s bound
parameters will be freed after reply_'s. I need to think about it more, but my
instinct is that that's undesirable.

[awong, 2011/08/16 02:12:13]

I think the delete this is good enough to force the destruction of |task_| and
|reply_|.

Good point about the ordering though. It'd be nice to define an ordering in the
API contract. I agree that reply feels like it should be destroyed first.  Will
make that change tomorrow.

[willchan no longer on Chromium, 2011/08/16 14:50:56]

I won't push further, but I just wonder if there's ever a case where reply_ may
have expected that task_ should already have been destroyed. It's possible that
there's behavior in the destructor of a bound argument. The API needs to dictate
the lifetime expectations. My instinct again was that |task_|'s bound arguments
should be destroyed prior to the execution of |reply_|. I haven't thought about
it too much though.

[awong, 2011/08/17 03:36:59]

AH! I see what you're saying now.  Yes. I can see that being somewhat useful in
ensuring people don't depend that the bindings in task outlive reply.

I've changed the code to force this, and documented the contract in the API.

+  DCHECK(origin_loop_->BelongsToCurrentThread());
+  reply_.Run();
+
+  // Cue mission impossible theme.
+  delete this;
+}
+
+}  // namespace internal
+
 }  // namespace base