Fixed example in MessageLoop::ReleaseSoon comment
The previous version could cause race condition if for whatever reason ReleaseSoon finished releasing on another thread before we got to "foo = NULL"
BUG=
Review URL: https://codereview.chromium.org/301943003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@273879 0039d316-1c4b-4281-b951-d872f2087c98
CrOS-Libchrome-Original-Commit: b76b02780f98983a6da062d68fc28c7ed37f2611
diff --git a/base/message_loop/message_loop.h b/base/message_loop/message_loop.h
index 25891c5..165299d 100644
--- a/base/message_loop/message_loop.h
+++ b/base/message_loop/message_loop.h
@@ -208,15 +208,16 @@
// released on a particular thread.
//
// A common pattern is to manually increment the object's reference count
- // (AddRef), issue a ReleaseSoon, then clear the pointer. The reference count
+ // (AddRef), clear the pointer, then issue a ReleaseSoon. The reference count
// is incremented manually to ensure clearing the pointer does not trigger a
// delete and to account for the upcoming decrement (ReleaseSoon). For
// example:
//
// scoped_refptr<Foo> foo = ...
- // foo.AddRef();
- // message_loop->ReleaseSoon(foo.get());
+ // foo->AddRef();
+ // Foo* raw_foo = foo.get();
// foo = NULL;
+ // message_loop->ReleaseSoon(raw_foo);
//
// NOTE: This method may be called on any thread. The object will be
// released (and thus possibly deleted) on the thread that executes