Bug 177375 – WeakPtrFactory should populate m_ref lazily.

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[zalan]

-the first time createWeakPtr is called.

[Radar WebKit Bug Importer]

<rdar://problem/34600468>

[zalan]

Created attachment 321579 [details]
Patch

[zalan]

Created attachment 321580 [details]
Patch

[zalan]

Created attachment 321584 [details]
Patch

[Geoffrey Garen]

Comment on attachment 321584 [details]
Patch

r=me when it builds

[zalan]

Created attachment 321603 [details]
Patch

[zalan]

Created attachment 321612 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 321612 [details]
Patch

Rejecting attachment 321612 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'validate-changelog', '--check-oops', '--non-interactive', 321612, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

ChangeLog entry in Source/WTF/ChangeLog contains OOPS!.

Full output: http://webkit-queues.webkit.org/results/4633838

[zalan]

Created attachment 321614 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 321614 [details]
Patch

Clearing flags on attachment: 321614

Committed r222422: <http://trac.webkit.org/changeset/222422>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Comment on attachment 321614 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=321614&action=review

Thrilled to see this change! I had a very old patch in my git repository trying to do the same thing, but I never got it working 100%.

> Source/WTF/wtf/WeakPtr.h:56
>      explicit WeakReference(T* ptr)

Can we change this constructor to take a reference instead of a pointer?

> Source/WTF/wtf/WeakPtr.h:-87
> -#ifndef NDEBUG
> -    ThreadIdentifier m_boundThread;
> -#endif

What’s the rationale for removing the thread checking? Do we think that clients are now more sophisticated now and don’t need the help catching incorrect uses any longer? Or was it too hard to re-implement this? Or some other reason?

[Geoffrey Garen]

> What’s the rationale for removing the thread checking? Do we think that
> clients are now more sophisticated now and don’t need the help catching
> incorrect uses any longer? Or was it too hard to re-implement this? Or some
> other reason?

Too hard to reimplement: We (validly) use pointers on multiple threads, and one of the first pointers we changed into a weak pointer fired this assertion.

You could imagine retaining this assertion as the default, with an escape hatch for "this pointer can be used on multiple threads". When we tried that with RefPtr, we eventually had to give it up because too many things needed the escape hatch. I'm hoping WeakPtr will be as successful as RefPtr.