Right now, hold the cache lock while we're doing I/O for opening, closing, and reading metadat in the cache (pehaps other times). We should release the lock when we're doing this so as to not block other threads that may be waiting on the lock.

(One of the sources of b2g jank that we prefer not to talk about.)

We don't like to talk about this.

Michal - when you have a patch up can you make sure to get feedback on it from Taras and :vladan?

There are too many possible call stacks ending up doing IO in nsDiskCacheMap::ReadDiskCacheEntry(). This patch reduces lot of them by replacing call to ProcessPendingRequests() by async call. Try server https://tbpl.mozilla.org/?tree=Try&rev=6d07fd5e58d5 is not green, but most of the failures seem to be unrelated to this patch. Asking for feedback instead of review because of xpcshell failures that still need to be resolved.

Comment on attachment 722487 [details] [diff] [review] replace calls to nsCacheService::ProcessPendingRequests() with async call when possible Cancelling feedback based on the new plans.

The biggest source of jank is actually from SetExpirationTime and is one of biggest chromehang issue after Plugins/GG/CC: http://mxr.mozilla.org/mozilla-central/source/netwerk/cache/nsCacheEntryDescriptor.cpp#200 This means we will wait for an I/O to complete in another thread just to update an integer. Can't we just mitigate this problem by doing PostTask to the cache thread?

Question is: can nsCacheEntryDescriptor.mCacheEntry be nullified (by call to ClearCacheEntry()) while the descriptor is still referenced? I assume it can. Then we cannot check or in any way call on mCacheEntry while not holding the global lock. This will of course not be the case in the new design ;)

Sorry: (In reply to Honza Bambas (:mayhemer) from comment #7) > I assume it can *NOT*.

does not apply to new cache