Implementation of PostTaskAndReply() in MessageLoopProxy and BrowserThread.

base/task.cc

 // Copyright (c) 2011 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 "base/task.h"
 
+#include "base/bind.h"
+#include "base/message_loop_proxy.h"
+
 Task::Task() {
 }
 
 Task::~Task() {
 }
 
 CancelableTask::CancelableTask() {
 }
 
 CancelableTask::~CancelableTask() {
@@ skipping 39 matching lines @@
   task_->Run();
   delete task_;
   task_ = NULL;
 }
 
 // Don't leak tasks by default.
 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