[Webkit-unassigned] [Bug 82287] MemoryCache should adopt our standard RefCounted model for object lifetime

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Nate Chapin <japhet at chromium.org>  2012-05-22 14:59:48 PST ---
(In reply to comment #9)
> (From update of attachment 143354 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=143354&action=review
> 
> I'm excited about this change, but unclear how this is going to work for clients?  Previously I thought clients were the only way that resources stayed alive.  Now I guess clients will hold a ref to the resource?  And the resource will keep weak pointers to the clients?

The existing model is that there is a long list of things that can keep a CachedResource alive:

bool canDelete() const { return !hasClients() && !m_loader && !m_preloadCount && !m_handleCount && !m_resourceToRevalidate && !m_proxyResource; }

The general strategy of my patch was to represent each of these clauses with a RefPtr somewhere.

Traditionally, clients kept a resource alive both by registering as a client and by holding a CachedResourceHandle (which increments m_handleCount). The model is now that CachedResourceClients are expected to hold a CachedResourceHandle, which in turn holds RefPtr to the CachedResource. I believe the CachedResourceHandle is still necessary for the time being, as it is a core part of 304 handling.



> 
> > Source/WebCore/loader/ImageLoader.cpp:116
> > +    RefPtr<CachedImage> oldImage = m_image.get();
> 
> You could do .release() and unconditionally set m_image from newImage here?

I'll look at it more, I had attempted to make this patch as un-clever as possible for the first pass.

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