Bug 107105 – Teach Functional.h about WeakPtr

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Adam Barth]

Teach Functional.h about WeakPtr

[Adam Barth]

Created attachment 183144 [details]
Patch

[Eric Seidel (no email)]

Anders will want to see this. :)

[Eric Seidel (no email)]

Comment on attachment 183144 [details]
Patch

This seems super-useful.

[Darin Adler]

Comment on attachment 183144 [details]
Patch

Anders, are you going to review?

[Anders Carlsson]

Comment on attachment 183144 [details]
Patch

Nice, I didn't even know we had a WeakPtr type. I'd like to know about its semantics:

Is it thread-safe? If not, it seems like this is a bad idea since we're essentially passing objects between two threads here. If it is, then it seems like there needs to be an atomic operation to temporarily make the weak pointer strong so we're not trying to call it on one thread while it's being destroyed on another thread.

[Adam Barth]

> Nice, I didn't even know we had a WeakPtr type.

I just added it a couple days ago:

http://trac.webkit.org/browser/trunk/Source/WTF/wtf/WeakPtr.h

> I'd like to know about its semantics:
> 
> Is it thread-safe? If not, it seems like this is a bad idea since we're essentially passing objects between two threads here. If it is, then it seems like there needs to be an atomic operation to temporarily make the weak pointer strong so we're not trying to call it on one thread while it's being destroyed on another thread.

There are two pieces to a WeakPtr: (1) the WeakPtr itself and (2) the underlying WeakReference.  The WeakReference is ThreadSafeRefCounted, which means you can hold a WeakPtr to an object on any thread.  However, access to the referenced object itself is not thread-safe because there is a race between the "clear" function, which zeros out the raw pointer to the object, and the "get" function, which retrieves the raw pointer.  That means, "get" and "clear" must always be called on the same thread.  WeakReference has ASSERTs to enforce this invariant.

From the point of view of Functional, that means that you can call "bind" on any thread (assuming you have a WeakPtr to the object), but you can only actually run the Function on the object's "home" thread (the thread on which the object will be destroyed---the same one whose identifier is stored in WeakReference::m_boundThread).  If you try to run the Function on the wrong thread, you'll hit an ASSERT in WeakPtr.h.

[Anders Carlsson]

Comment on attachment 183144 [details]
Patch

Thanks, that makes sense.

[Adam Barth]

Comment on attachment 183144 [details]
Patch

Thanks for the review.  :)

[WebKit Review Bot]

Comment on attachment 183144 [details]
Patch

Clearing flags on attachment: 183144

Committed r140040: <http://trac.webkit.org/changeset/140040>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.