[Webkit-unassigned] [Bug 139339] [Curl] Cache entry is sometimes deleted when request receives a not modified response.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 10 07:48:01 PST 2014


--- Comment #9 from peavo at outlook.com ---
(In reply to comment #7)
> Comment on attachment 242927 [details]
> Patch
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=242927&action=review
> > Source/WebCore/ChangeLog:9
> > +        but the cache entry has already been deleted by another request.
> How would another request have already deleted the cached response? I'm not
> entirely convinced that locking will solve this problem.

Another request will delete and rebuild the entry if it receives a 200 OK response for the same url. The problem is usually seen with css files, which often are loaded by several requests concurrently, resulting in documents without styling. 

> > Source/WebCore/platform/network/curl/CurlCacheEntry.h:83
> > +    int m_lockCount;
> Why is this not a bool? How would more than one request get the lock?

I have probably used the wrong term here. It's not an exclusive lock, it's more of a reference count of the cache entry, to make sure nobody is deleting the cache entry when there are pending request, which will need the entry soon.

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/20141210/6e96eb77/attachment-0002.html>

More information about the webkit-unassigned mailing list