Thanks. http://codereview.chromium.org/2827043/diff/19001/20003 File net/disk_cache/backend_unittest.cc (right): http://codereview.chromium.org/2827043/diff/19001/20003#newcode405 net/disk_cache/backend_unittest.cc:405: // On a slow system we may end ...

Thanks.
http://codereview.chromium.org/2827043/diff/19001/20003
File net/disk_cache/backend_unittest.cc (right):
http://codereview.chromium.org/2827043/diff/19001/20003#newcode405
net/disk_cache/backend_unittest.cc:405: // On a slow system we may end up
evicting everything not currently in use.
On 2010/07/08 02:18:14, gavinp wrote:
> Does reordering the assert for OpenEntry(second) and OpenEntry(first) make a
> difference? Why?
The problem with the old code is that it tests that only one entry (the oldest
one) is evicted. Eviction actually happens when the max_size limit is reached,
when an entry is charged by the space. In this case, it happens when "second" is
flushed from it's destructor... in other words, when the posted Close() executes
on the cache thread.
The issue with a slow system (valgrind) is that eviction of a single entry takes
more than 20 ms so we assume that we must keep working on that, and we post a
task to continue the eviction process... and given that we now have two threads,
that second task will actually run and evict the second entry so we'll fail to
open it.
By opening "second" right away, we don't give the eviction code a chance to
evict it, because when that posted task to evict runs, the entry is in use and
will not be evicted.
The sad thing is that now that we have two threads (and control for only one),
there are a lot of tests that are quite delicate in the order of events needed
to trigger the behavior under test :(