diff options
| author | chron@google.com <chron@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-02-17 01:52:42 +0000 |
|---|---|---|
| committer | chron@google.com <chron@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-02-17 01:52:42 +0000 |
| commit | 04c4cd34e8cbc163215333f57e6698b8a166cf4b (patch) | |
| tree | bfe7faaf2c2557d3b316431f1f19b746f6006322 /AUTHORS | |
| parent | c34711fce84fe80bda2d105bbfdfa42494eb6210 (diff) | |
| download | chromium_src-04c4cd34e8cbc163215333f57e6698b8a166cf4b.zip chromium_src-04c4cd34e8cbc163215333f57e6698b8a166cf4b.tar.gz chromium_src-04c4cd34e8cbc163215333f57e6698b8a166cf4b.tar.bz2 | |
We dump all of the originals_ metahandles to the dirty_metahandles index and then check later to see if they are actually dirty. Arguably this is unnecessary, but I've been lead to believe (and my quick debugging has shown) that metahandles used in a WriteTransaction tend to get dirtied. The majority of times the TakeSnapshot... loop executes now, the dirty_metahandles set is empty.There's also the benefit that it's pretty clear that the ScopedKernelLock, which is needed to look up an entry by metahandle, is held when we're iterating through the [possibly] dirty_metahandles in the TakeSnapshot... function. This is arguably less true of the WriteTransaction deconstructor. But if there's a different way to get the new dirty flag from an original then that's probably the way to go. I found out the hard way that checking the dirty flag of the original means nothing as I was leaking away metahandles.I added a short protected function to Directory that acts as a wrapper for the kernel_->dirty_metahandles->insert function. It seemed like the thing to do to decouple it somewhat. Plus we can check there to see if it's actually dirty if that's what we decide to do.We piggy-back on the transaction lock to save us thread-safety concerns in dealing with the dirty_metahandles set.
One more thing: if I'm screwing up any meta-stuff here please don't be afraid to share. I'd hate to be writing too much, too little, or about the wrong stuff in these things :)
Added two unit tests to ensure that the WriteTransaction deconstructor and TakeSnapshotForSaveChanges function were cooperating. One makes sure that all of the dirty metahandles show up again and the other makes sure that the non-dirty dirty_metahandles are disgarded. I had to move some things out of the anonymous namespace in order for the FRIEND_TEST macro to work correctly.
Old patch: http://codereview.chromium.org/585007
BUG=19901
TEST=SyncableDirectoryTest.TakeSnapshotGetsAllDirtyHandlesTest, SyncableDirectoryTest.TakeSnapshotGetsOnlyDirtyHandlesTest
AUTHOR=Alex Gartrell (AlexGartrell@gmail.com)
chron submitting on original author's behalf.
Review URL: http://codereview.chromium.org/598006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39180 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'AUTHORS')
| -rw-r--r-- | AUTHORS | 1 |
1 files changed, 1 insertions, 0 deletions
@@ -63,3 +63,4 @@ Vernon Tang <vt@foilhead.net> Alexander Sulfrian <alexander@sulfrian.net> Philippe Beaudoin <philippe.beaudoin@gmail.com> Mark Hahnenberg <mhahnenb@gmail.com> +Alex Gartrell <alexgartrell@gmail.com> |