[webkit-reviews] review denied: [Bug 199857] [WTF] Thread::removeFromThreadGroup leaks weak pointers. : [Attachment 374293] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jul 26 19:37:40 PDT 2019
Yusuke Suzuki <ysuzuki at apple.com> has denied Takashi Komori
<Takashi.Komori at sony.com>'s request for review:
Bug 199857: [WTF] Thread::removeFromThreadGroup leaks weak pointers.
https://bugs.webkit.org/show_bug.cgi?id=199857
Attachment 374293: Patch
https://bugs.webkit.org/attachment.cgi?id=374293&action=review
--- Comment #4 from Yusuke Suzuki <ysuzuki at apple.com> ---
Comment on attachment 374293
--> https://bugs.webkit.org/attachment.cgi?id=374293
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=374293&action=review
Nice catch! Discussed with Mark about whether this works with the current
protocol of ThreadGroup and Thread, and we think that the key is that we should
remove ThreadGroup unconditionally without using `weakPtr.lock()`. To achieve
it simply with O(1), I commented about the HashMap based approach here. Does it
seem good for you too?
> Source/WTF/wtf/Threading.cpp:259
> return sharedPtr.get() == &threadGroup;
> return false;
> });
Nice catch! I think the key is that, if we can just remove threadGroup
unconditionally from this list, it should work.
So, ideally, the code should be like,
return &threadGroup == weakPtr.get();
Then it works. But the problem is that std::weak_ptr does not have an original
raw pointer. So, can you change the code like,
1. Instead of holding a Vector<std::weak_ptr<ThreadGroup>>, let's hold
HashMap<ThreadGroup*, std::weak_ptr<ThreadGroup>>
2. Remove the entry from that hash map in this function
3. In L214, iterate the hash map and collect shared_ptr from the value's
weak_ptr
Or, another simple way is that holding struct { ThreadGroup* threadGroup;
std::weak_ptr<ThreadGroup> weakPtr } in a Vector, but I think HashMap one is
better.
More information about the webkit-reviews
mailing list