Closed Bug 716172 Opened 10 years ago Closed 10 years ago
Waiting for ns
Cache Service::Lock on the main thread
I'm finding that it's pretty common to spend 3s or so waiting for nsCacheService::Lock on the main thread. This is on Win 7 with the attached patch. The strange thing is that it's not obvious that the browser is actually unresponsive during that time, so I might be doing something wrong, or understanding the results wrong.
I was just using Zimbra, and when deleting an email, it took extra long (i.e., showing the OS's busy cursor for 1s+), and an "action cache_lock 1600.000" printed out. So I'm pretty sure these can cause serious visible delays.
Was the busy cursor on the Zimbra UI or the browser chrome. Zimbra uses sync XHR, which will cause the busy cursor in the content area, so that could be what you're seeing.
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #2) > Was the busy cursor on the Zimbra UI or the browser chrome. Zimbra uses > sync XHR, which will cause the busy cursor in the content area, so that > could be what you're seeing. It seems that the busy cursor is in the Zimbra UI (i.e., if I leave the cursor over the title bar, then I don't get a busy cursor) but the browser still locks up. I'm still getting these pauses after the cache-closing bug got fixed. One I got today looks like this: event xpcom 204019417.0 5137.0 47 samples: NtWaitForSingleObject RtlIntegerToUnicodeString PR_Lock nsCacheService::Lock nsCacheService::OpenCacheEntry nsCacheSession::OpenCacheEntry nsHttpChannel::DoInvalidateCacheEntry nsHttpChannel::MaybeInvalidateCacheEntryForSubsequentGet nsHttpChannel::ProcessResponse nsHttpChannel::OnStartRequest nsInputStreamPump::OnStateStart nsInputStreamPump::OnInputStreamReady
We're discussing this in bug 717761
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 717761
You need to log in before you can comment on or make changes to this bug.