summaryrefslogtreecommitdiffstats
path: root/media/mf/mft_h264_decoder.h
diff options
context:
space:
mode:
authorshess@chromium.org <shess@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-09-02 23:30:43 +0000
committershess@chromium.org <shess@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-09-02 23:30:43 +0000
commitb57c07779e9f1e6af2d45d89102d8772d6b72819 (patch)
tree0ea75672b21996dff5330515ac2f04a7a59f60e2 /media/mf/mft_h264_decoder.h
parent44e6e916d72360059c8ea044a3a11f76211196d5 (diff)
downloadchromium_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