Disk Cache: Replace the backend pointer of the ChildrenDeleter...

Disk Cache: Replace the backend pointer of the ChildrenDeleter
with a weak pointer to avoid crashing at shutdown.

BUG=50082
TEST=net_unittests


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=53838

[gavinp, 2010-07-27 15:29:44]

LGTM.

Are there any other places that we should be tracking down ptrs to the
BackendImpl and adding weak pointers?

http://codereview.chromium.org/3054012/diff/1/4
File net/disk_cache/entry_unittest.cc (right):

http://codereview.chromium.org/3054012/diff/1/4#newcode1295
net/disk_cache/entry_unittest.cc:1295: public:
" public:"

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Class_...

http://codereview.chromium.org/3054012/diff/1/4#newcode1303
net/disk_cache/entry_unittest.cc:1303: private:
" private:"

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Class_...

http://codereview.chromium.org/3054012/diff/1/4#newcode1336
net/disk_cache/entry_unittest.cc:1336: cache_ = NULL;
What does this do?

[rvargas (doing something else), 2010-07-27 18:26:30]

Thanks.

I found out this issue by looking at other places that were doing PostTask after
fixing the last bug (in other words, not from a crash report).

As from other places that keep pointers to the backend, they should be deleted
directly by the backend destructor.

The only exception is an EntryImpl, but I don't think we should convert that
pointer to a weak one: when the cache goes away, surviving transactions should
stop issuing requests to any entry that they reference... and if we need to be
explicit about it, we already keep track of open entries so we could do
something when the backend goes away.

http://codereview.chromium.org/3054012/diff/1/4
File net/disk_cache/entry_unittest.cc (right):

http://codereview.chromium.org/3054012/diff/1/4#newcode1336
net/disk_cache/entry_unittest.cc:1336: cache_ = NULL;
On 2010/07/27 15:29:44, gavinp wrote:
> What does this do?
> 

We deleted the cache in the callback, but the test's TearDown doesn't know about
it and will attempt to destroy the object again. I added a comment.