[Webkit-unassigned] [Bug 143056] Use std::unique_ptr instead of PassOwnPtr|OwnPtr for ResourceResponse

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 31 05:38:55 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=143056

--- Comment #5 from Joonghun Park <jh718.park at samsung.com> ---
(In reply to comment #4)
> Comment on attachment 249460 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=249460&action=review
> 
> > Source/WebCore/loader/WorkerThreadableLoader.cpp:169
> >          delete responseData;
> 
> I wonder if we should delete responseData. Because response.copyData()
> releases own pointer in 163 line. Then *responseData* looks manage the
> memory.
> 

As you said, after we call response.copyData().leakPtr(), it releases the raw pointer of CrossThreadResourceResponseData. And it is passed into lambda, and in lambda body, it is used as parameter of unique_ptr ctor. As you can see in StdLibExtras.h:335, make_unique() is only a wrapper of unique_ptr ctor. In this case, we already have CrossThreadResourceResponseData*, and we want to use it. So no need to use make_unique, that is why I use std::unique_ptr<CrossThreadResourceResponseData>(responseData) in 166 line.

> > Source/WebCore/platform/network/cf/ResourceResponse.h:105
> > +    void doPlatformAdopt(std::unique_ptr<CrossThreadResourceResponseData>) { }
> 
> One question. Can't we move doPlatformCopyData() and doPlatformAdopt()
> declarations to ResourceResponseBase.h ?

Well, I guess moving this to the ResourceResponseBase.h is possible.
But it seems that the name is intended for the platform specific use(e.g.cf, curl, soup specific).
So I doubt that it would be needed though the current implementation state is the same among them.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150331/44ec8cb0/attachment-0002.html>


More information about the webkit-unassigned mailing list