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

[bugzilla-daemon at webkit.org]

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

--- 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>