Commit 484e71eb authored by dalecurtis's avatar dalecurtis Committed by Commit bot

Don't immediately timeout upon range request cache lock.

BUG=408765
TEST=back-to-back requests don't bypass the cache lock.

Review URL: https://codereview.chromium.org/579393002

Cr-Commit-Position: refs/heads/master@{#295640}
parent eb7b46e6
......@@ -1390,10 +1390,10 @@ int HttpCache::Transaction::DoAddToEntry() {
if (bypass_lock_for_test_) {
OnAddToEntryTimeout(entry_lock_waiting_since_);
} else {
int timeout_secs = 20;
int timeout_milliseconds = 20 * 1000;
if (partial_ && new_entry_->writer &&
new_entry_->writer->range_requested_) {
// Immediately timeout and bypass the cache if we're a range request and
// Quickly timeout and bypass the cache if we're a range request and
// we're blocked by the reader/writer lock. Doing so eliminates a long
// running issue, http://crbug.com/31014, where two of the same media
// resources could not be played back simultaneously due to one locking
......@@ -1403,13 +1403,17 @@ int HttpCache::Transaction::DoAddToEntry() {
// entirely for all range requests to a resource beyond the first. This
// is however a much more succinct solution than the alternatives, which
// would require somewhat significant changes to the http caching logic.
timeout_secs = 0;
//
// Allow some timeout slack for the entry addition to complete in case
// the writer lock is imminently released; we want to avoid skipping
// the cache if at all possible. See http://crbug.com/408765
timeout_milliseconds = 25;
}
base::MessageLoop::current()->PostDelayedTask(
FROM_HERE,
base::Bind(&HttpCache::Transaction::OnAddToEntryTimeout,
weak_factory_.GetWeakPtr(), entry_lock_waiting_since_),
TimeDelta::FromSeconds(timeout_secs));
TimeDelta::FromMilliseconds(timeout_milliseconds));
}
}
return rv;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment