Bug 47423 - [chromium] Update WebBlobData to adapt to BlobData change in terms of handling string data item
Summary: [chromium] Update WebBlobData to adapt to BlobData change in terms of handlin...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Jian Li
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-08 10:30 PDT by Jian Li
Modified: 2010-10-12 17:42 PDT (History)
6 users (show)

See Also:


Attachments
Proposed Patch (12.93 KB, patch)
2010-10-08 10:48 PDT, Jian Li
fishd: review-
jianli: commit-queue-
Details | Formatted Diff | Diff
Proposed Patch (15.06 KB, patch)
2010-10-11 10:51 PDT, Jian Li
jianli: commit-queue-
Details | Formatted Diff | Diff
Proposed Patch (15.46 KB, patch)
2010-10-11 10:56 PDT, Jian Li
fishd: review-
jianli: commit-queue-
Details | Formatted Diff | Diff
Proposed Patch (19.21 KB, patch)
2010-10-12 11:15 PDT, Jian Li
fishd: review-
jianli: commit-queue-
Details | Formatted Diff | Diff
Proposed Patch (18.11 KB, patch)
2010-10-12 12:55 PDT, Jian Li
fishd: review+
jianli: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jian Li 2010-10-08 10:30:21 PDT
We need to update WebKit implementation WebBlobData to adapt to BlobData change introduced in https://bugs.webkit.org/show_bug.cgi?id=46543.
Comment 1 Jian Li 2010-10-08 10:48:45 PDT
Created attachment 70268 [details]
Proposed Patch
Comment 2 WebKit Review Bot 2010-10-08 12:23:56 PDT
Attachment 70268 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/4192152
Comment 3 Darin Fisher (:fishd, Google) 2010-10-09 14:11:33 PDT
Comment on attachment 70268 [details]
Proposed Patch

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

> WebKit/chromium/public/WebBlobData.h:48
> +class WebRawData {

please put this in a separate header file.  one class/struct per header please.

i would give this a better name because we already have WebData.  what you have
here it seems is a container for a |const char*| and a length.  that means this
class does not own the data.  WebDependentData or WebDataPiece might be good
names.

> WebKit/chromium/public/WebBlobData.h:56
> +    WEBKIT_API void reset()

note: these do not need WEBKIT_API since they are implemented inline.  you
only need WEBKIT_API on methods that need to be exported from webkit.dll.

> WebKit/chromium/public/WebBlobData.h:86
> +        WebRawData data;

have you considered using WebData here instead?  why do you want this
class to not own the data?
Comment 4 Jian Li 2010-10-11 10:51:51 PDT
Created attachment 70452 [details]
Proposed Patch
Comment 5 Jian Li 2010-10-11 10:56:14 PDT
Created attachment 70453 [details]
Proposed Patch
Comment 6 Jian Li 2010-10-11 11:01:10 PDT
(In reply to comment #3)
> (From update of attachment 70268 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=70268&action=review
> 
> > WebKit/chromium/public/WebBlobData.h:48
> > +class WebRawData {
> 
> please put this in a separate header file.  one class/struct per header please.
> 
> i would give this a better name because we already have WebData.  what you have
> here it seems is a container for a |const char*| and a length.  that means this
> class does not own the data.  WebDependentData or WebDataPiece might be good
> names.

Renamed to WebDependentData and moved to a separate file.

> 
> > WebKit/chromium/public/WebBlobData.h:56
> > +    WEBKIT_API void reset()
> 
> note: these do not need WEBKIT_API since they are implemented inline.  you
> only need WEBKIT_API on methods that need to be exported from webkit.dll.

Done.

> 
> > WebKit/chromium/public/WebBlobData.h:86
> > +        WebRawData data;
> 
> have you considered using WebData here instead?  why do you want this
> class to not own the data?

Yes, I have looked into WebData, but decided not to use it because we want to avoid copying the string data. Since the lifetime of the string data is controlled by the BlobData and thus WebBlobData, we do not need to use WebData to copy it over.
Comment 7 WebKit Review Bot 2010-10-11 12:19:01 PDT
Attachment 70453 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/4278027
Comment 8 Darin Fisher (:fishd, Google) 2010-10-11 14:57:23 PDT
Comment on attachment 70453 [details]
Proposed Patch

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

> WebKit/chromium/public/WebBlobData.h:51
> +        WebDependentData data;

This scares me because you are putting a memory address into a data structure,
and relying on the guy who created the WebBlobData to keep the memory address
valid.  It would be much better to use WebData.

Why don't you change WebCore::BlobDataItem::data to be of type RefPtr<SharedBuffer>
instead of CString?  Then, the conversion from WebData to RefPtr<SharedBuffer>
would be super cheap.
Comment 9 Jian Li 2010-10-11 15:06:59 PDT
(In reply to comment #8)
> (From update of attachment 70453 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=70453&action=review
> 
> > WebKit/chromium/public/WebBlobData.h:51
> > +        WebDependentData data;
> 
> This scares me because you are putting a memory address into a data structure,
> and relying on the guy who created the WebBlobData to keep the memory address
> valid.  It would be much better to use WebData.
> 
> Why don't you change WebCore::BlobDataItem::data to be of type RefPtr<SharedBuffer>
> instead of CString?  Then, the conversion from WebData to RefPtr<SharedBuffer>
> would be super cheap.

I can't use SharedBuffer since it is not thread-safe. I have to make the representation of string data be thread-safe so that the blob data can be passed from worker thread to main thread.
Comment 10 Jian Li 2010-10-12 11:15:32 PDT
Created attachment 70544 [details]
Proposed Patch
Comment 11 Jian Li 2010-10-12 11:16:26 PDT
> Why don't you change WebCore::BlobDataItem::data to be of type RefPtr<SharedBuffer>
> instead of CString?  Then, the conversion from WebData to RefPtr<SharedBuffer>
> would be super cheap.

Changed to do something similar to WebData by introducing WebThreadSafeData to wrap RawData.
Comment 12 Darin Fisher (:fishd, Google) 2010-10-12 12:01:25 PDT
Comment on attachment 70544 [details]
Proposed Patch

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

> WebKit/chromium/public/WebThreadSafeData.h:37
> +namespace WebCore { class RawData; }

where is RawData defined?  i cannot find it in the source tree.

> WebKit/chromium/public/WebThreadSafeData.h:84
> +    WebThreadSafeDataPrivate* m_private;

please take advantage of WebPrivatePtr<T>.  that is the new way of wrapping
a reference counted WebCore type.  see WebNode.h for example.
Comment 13 Jian Li 2010-10-12 12:55:16 PDT
Created attachment 70558 [details]
Proposed Patch
Comment 14 Jian Li 2010-10-12 12:57:00 PDT
(In reply to comment #12)
> (From update of attachment 70544 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=70544&action=review
> 
> > WebKit/chromium/public/WebThreadSafeData.h:37
> > +namespace WebCore { class RawData; }
> 
> where is RawData defined?  i cannot find it in the source tree.

It is defined in BlobData.h in the patch for bug 46543 (https://bugs.webkit.org/show_bug.cgi?id=46543).
Note that I am going to update this patch to move RawData out of "struct BlobDataItem" to allow forward declaration.

> 
> > WebKit/chromium/public/WebThreadSafeData.h:84
> > +    WebThreadSafeDataPrivate* m_private;
> 
> please take advantage of WebPrivatePtr<T>.  that is the new way of wrapping
> a reference counted WebCore type.  see WebNode.h for example.

Done.
Comment 15 WebKit Review Bot 2010-10-12 13:43:52 PDT
Attachment 70558 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/4373012
Comment 16 WebKit Review Bot 2010-10-12 16:09:43 PDT
http://trac.webkit.org/changeset/69611 might have broken Chromium Win Release
Comment 17 Jian Li 2010-10-12 17:42:39 PDT
Committed as http://trac.webkit.org/changeset/69611.