[Webkit-unassigned] [Bug 37874] Provide mechanism to cache metadata for a resource

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 5 11:34:35 PDT 2010


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





--- Comment #20 from Adam Barth <abarth at webkit.org>  2010-05-05 11:34:33 PST ---
(In reply to comment #19)
> I have a couple of questions inline below. I'll hold off on uploading the next
> patch until those are answered.
> 
> By the way, do you think that reinterpret_cast is okay or should I ask
> around/research it a little more?

I'd rather we didn't have to reinterpret_cast, but I'm not sure where's a way
around it.

> > This is getting close.  I'd like to see this code used by something so it's not
> > dead code though.  :)
> 
> This patch is hairy enough that I don't think I should add to it. I'll upload a
> separate patch for bindings/v8 now. Should it use this bug or a new bug?

Good idea.  Please use a separate bug.  We can cross-link them if we need to
using the "blocks" field.

> > WebCore/loader/CachedMetadataStore.h:107
> >  +      static const size_t dataTypeIDStart = 0;
> > This constant also doesn't really help.
> 
> I disagree. I think it is crucial for readability to have the offsets of the
> format in one place. If I just inline it, then I'm left with code that says
> readUnsigned(0) instead of readUnsigned(dataTypeIDStart). If you still feel
> strongly then I'll defer to you and inline it.

Ok.

> > WebCore/loader/CachedMetadataStore.h:54
> >  +      static PassOwnPtr<CachedMetadataStore> deserialize(const char* data,
> > size_t size)
> > Why two parameters instead of a const Vector<char>&  ?
> 
> This is a side-effect of the main API. It looks like:
> 
> Load:     ResourceLoader::didReceiveCachedMetadata(const char*, int)
> Persist:  ResourceHandle::cacheMetadata(const ResourceResponse&, const
> Vector<char>&)
> 
> They should probably both use Vectors or both use char*/length. My thought is
> to remove the Vector in favor of char*/length. But I wanted to confirm with you
> before making the change.

Using Vector is generally better because it's clear who owns the memory.  The
main reason to use char* + length is if the malloc in Vector is too expensive
or there's a critical memcpy that can't be removed.

> > WebCore/loader/CachedMetadata.h:39
> >  +  class CachedMetadata : public RefCounted<CachedMetadata> {
> > I don't understand the role this class plays.  How is it different than
> > Vector<char> ?  Maybe because it doesn't take ownership of the bytes?
> 
> It is basically a class to point to data without owning it (to avoid a copy).
> This allows CachedResource::cachedMetadata(unsigned) to return one object
> rather than the much uglier CachedResource::cachedMetadata(unsigned, const
> char**, int*). I couldn't find a suitable generic container in WebKit. Do you
> have a suggestion for a better way to return a pointer/length combination
> without a copy?

I guess my main concern is that the ownship of the memory is unclear.  How long
can the caller hold on to this object before it explodes?  I think this is the
problem that SharedBuffer is trying to solve.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list