Rename/re-comment tests and added new death tests for WeakPtr

base/memory/weak_ptr.h

 // Copyright (c) 2012 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.
 
 // Weak pointers help in cases where you have many objects referring back to a
 // shared object and you wish for the lifetime of the shared object to not be
 // bound to the lifetime of the referrers.  In other words, this is useful when
 // reference counting is not a good fit.
 //
 // Thread-safety notes:
-// When you get a WeakPtr (from a WeakPtrFactory or SupportsWeakPtr),
-// the WeakPtr becomes bound to the current thread. You may only
-// dereference the WeakPtr on that thread. However, it is safe to
-// destroy the WeakPtr object on another thread.
-// Since a WeakPtr object may be destroyed on a background thread,
-// querying WeakPtrFactory's HasWeakPtrs() method can be racy.
-//
+// When you get a WeakPtr (from a WeakPtrFactory or SupportsWeakPtr), the
+// WeakPtr becomes bound to the current thread. You may only dereference the
+// WeakPtr on that thread. However, it is safe to destroy the WeakPtr object
+// on another thread. Since a WeakPtr object may be destroyed on a background
+// thread, querying WeakPtrFactory's HasWeakPtrs() method can be racy.
+// On the other hand, the object that supports WeakPtr (extends
+// SupportsWeakPtr) will be bound to the first thread that creates a WeakPtr
+// pointing to it, and can not be deleted from other threads unless all
+// WeakPtrs are deleted. To work around of this, call

[Ryan Sleevi, 2012/07/10 00:06:44]

nit: To work around this

[kaiwang, 2012/07/10 22:21:19]

Done.

+// SupportsWeakPtr::DetachFromThread().

[Ryan Sleevi, 2012/07/10 00:06:44]

I'm not sure we should encourage calling DetachFromThread().

The behaviour being displayed is very much intentional - the WeakPtrFactory
should only disappear on the thread that is associated with all of the WeakPtrs.
The ThreadChecker that exists (and is used by DetachFromThread) is meant to
guard that.

Doing

Thread 1:
WeakPtr<Foo> foo = controller->AsWeakPtr();
controller->DetachFromThread();
thread_2->DeleteSoon(FROM_HERE, controller)

Is inherently dangerous, and it seems to be what the comment is suggesting.

[kaiwang, 2012/07/10 22:21:19]

Changed the wording.

 //
 // A common alternative to weak pointers is to have the shared object hold a
 // list of all referrers, and then when the shared object is destroyed, it
 // calls a method on the referrers to tell them to drop their references.  This
 // approach also requires the referrers to tell the shared object when they get
 // destroyed so that the shared object can remove the referrer from its list of
 // referrers.  Such a solution works, but it is a bit complex.
 //
 // EXAMPLE:
 //
@@ skipping 190 matching lines @@
     ref_ = internal::WeakReference();
     ptr_ = NULL;
   }
 
  private:
   friend class internal::SupportsWeakPtrBase;
   friend class SupportsWeakPtr<T>;
   friend class WeakPtrFactory<T>;
 
   WeakPtr(const internal::WeakReference& ref, T* ptr)
-      : WeakPtrBase(ref), ptr_(ptr) {
+      : WeakPtrBase(ref),
+        ptr_(ptr) {
   }
 
   // This pointer is only valid when ref_.is_valid() is true.  Otherwise, its
   // value is undefined (as opposed to NULL).
   T* ptr_;
 };
 
 // A class may extend from SupportsWeakPtr to expose weak pointers to itself.
 // This is useful in cases where you want others to be able to get a weak
 // pointer to your class.  It also has the property that you don't need to
@@ skipping 83 matching lines @@
 
  private:
   internal::WeakReferenceOwner weak_reference_owner_;
   T* ptr_;
   DISALLOW_IMPLICIT_CONSTRUCTORS(WeakPtrFactory);
 };
 
 }  // namespace base
 
 #endif  // BASE_MEMORY_WEAK_PTR_H_