Elaborate on the CancelableCallback docs

base/cancelable_callback.h

Index: base/cancelable_callback.h
diff --git a/base/cancelable_callback.h b/base/cancelable_callback.h
index 13cbd0c2139e10755e863bd3402a4ff4459db0e3..b91f7c0d6360f29816cf6b0985df70fb77510107 100644
--- a/base/cancelable_callback.h
+++ b/base/cancelable_callback.h
@@ -7,17 +7,23 @@
 // wrapped callback until this object is destroyed or Reset()/Cancel() are
 // called.
 //
-// NOTE:
+// NOTES:
 //
 // Calling CancelableCallback::Cancel() brings the object back to its natural,
 // default-constructed state, i.e., CancelableCallback::callback() will return
 // a null callback.
 //
+// It is NOT allowed to call CancelableCallback::Cancel() or
+// CancelableCallback::Reset() from the wrapped callback.
+//
 // THREAD-SAFETY:
 //
-// CancelableCallback objects must be created on, posted to, cancelled on, and
+// CancelableCallback objects must be posted to, cancelled on, reset on, and
 // destroyed on the same thread.
 //
+// CancelableCallback objects are allowed to be constructed on a different

[emaxx, 2017/03/01 03:37:54]

Hmm, thinking more on this, this added comment is actually misleading: while
it's allowed to construct CancelableCallback on a different thread, it's not
allowed to _destruct_ them there (unless one can guarantee that there are no
callbacks currently posted anywhere, but that's probably not a typical use
case).

As it's becoming quite hard to explain this here, I'm starting to think that
this whole different-thread-corner-case should be simply disallowed, as before.
Any thoughts on this?

+// thread than on which they will be used later.
+//
 //
 // EXAMPLE USAGE:
 //