diff options
author | shess@chromium.org <shess@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-09-02 23:30:43 +0000 |
---|---|---|
committer | shess@chromium.org <shess@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-09-02 23:30:43 +0000 |
commit | b57c07779e9f1e6af2d45d89102d8772d6b72819 (patch) | |
tree | 0ea75672b21996dff5330515ac2f04a7a59f60e2 /media/mf/mft_h264_decoder.h | |
parent | 44e6e916d72360059c8ea044a3a11f76211196d5 (diff) | |
download | chromium_src-b57c07779e9f1e6af2d45d89102d8772d6b72819.zip chromium_src-b57c07779e9f1e6af2d45d89102d8772d6b72819.tar.gz chromium_src-b57c07779e9f1e6af2d45d89102d8772d6b72819.tar.bz2 |
Final fixes for new safe-browsing storage.
In safe_browsing_database.cc, when inserting subs which have no
prefixes, calculate the add-chunk based on the entry's chunk, not the
sub chunk being processed. This matches the old code.
Revise safe_browsing_store* to trim deleted chunks as part of
processing rather than as part of reading. This means that more
data will be in memory, but it follows the old code, which
allowed subs to cancel adds before the add's chunk was deleted.
Without this, those subs will stay around until the sub chunk is
deleted (because their adds are not seen).
In safe_browsing_store_sqlite.cc, the previous code attempted to trick
SQLite into writing data efficiently by locking down the old tables
while writing the new ones. Due to our use of SQLITE_SECURE_DELETE,
this actually resulted in bigger files and more overall I/O. Modify
things to simply delete the data, instead.
BUG=28647
TEST=none
Review URL: http://codereview.chromium.org/3244012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58426 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'media/mf/mft_h264_decoder.h')
0 files changed, 0 insertions, 0 deletions