[sql] Use memory-mapped I/O for sql::Connection.

sql/connection_unittest.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/bind.h"
 #include "base/files/file_util.h"
+#include "base/files/memory_mapped_file.h"
 #include "base/files/scoped_file.h"
 #include "base/files/scoped_temp_dir.h"
 #include "base/logging.h"
 #include "base/metrics/statistics_recorder.h"
+#include "base/strings/stringprintf.h"
 #include "base/test/histogram_tester.h"
 #include "sql/connection.h"
 #include "sql/correct_sql_test_base.h"
 #include "sql/meta_table.h"
 #include "sql/statement.h"
 #include "sql/test/error_callback_support.h"
 #include "sql/test/scoped_error_ignorer.h"
 #include "sql/test/test_helpers.h"
 #include "testing/gtest/include/gtest/gtest.h"
 #include "third_party/sqlite/sqlite3.h"
@@ skipping 1270 matching lines @@
 
   samples = tester.GetHistogramSamplesSinceCreation(kCommitTime);
   ASSERT_TRUE(samples);
   // 100 for commit adjust, 1 for measuring COMMIT.
   EXPECT_EQ(101, samples->sum());
 
   samples = tester.GetHistogramSamplesSinceCreation(kAutoCommitTime);
   EXPECT_EQ(0, samples->sum());
 }
 
-}  // namespace
+// Make sure that OS file writes to a mmap'ed file are reflected in the memory
+// mapping of a memory-mapped file.  Normally SQLite writes to memory-mapped
+// files using memcpy(), which should stay consistent.  Our SQLite is slightly
+// patched to mmap read only, then write using OS file writes.  If the
+// memory-mapped version doesn't reflect the OS file writes, SQLite's
+// memory-mapped I/O should be disabled on this platform.
+TEST_F(SQLConnectionTest, MmapTest) {
+  {
+    sql::Statement s(db().GetUniqueStatement("PRAGMA mmap_size"));
+    ASSERT_TRUE(s.Step());
+    EXPECT_GT(s.ColumnInt64(0), 0);
+  }
+  db().Close();
+  const uint32 kFlags =
+      base::File::FLAG_OPEN_ALWAYS|base::File::FLAG_READ|base::File::FLAG_WRITE;
+  base::File f(db_path(), kFlags);
+  ASSERT_TRUE(f.IsValid());
+
+  // Create a file with a block of '0', a block of '1', and a block of '2'.
+  char buf[4096];
+  memset(buf, '0', sizeof(buf));
+  ASSERT_EQ(f.Write(0*sizeof(buf), buf, sizeof(buf)), (int)sizeof(buf));
+
+  memset(buf, '1', sizeof(buf));
+  ASSERT_EQ(f.Write(1*sizeof(buf), buf, sizeof(buf)), (int)sizeof(buf));
+
+  memset(buf, '2', sizeof(buf));
+  ASSERT_EQ(f.Write(2*sizeof(buf), buf, sizeof(buf)), (int)sizeof(buf));
+
+  // mmap the file and verify that everything looks right.
+  base::MemoryMappedFile m;
+  ASSERT_TRUE(m.Initialize(db_path()));
+
+  memset(buf, '0', sizeof(buf));
+  ASSERT_EQ(0, memcmp(buf, m.data() + 0*sizeof(buf), sizeof(buf)));
+
+  memset(buf, '1', sizeof(buf));
+  ASSERT_EQ(0, memcmp(buf, m.data() + 1*sizeof(buf), sizeof(buf)));
+
+  memset(buf, '2', sizeof(buf));
+  ASSERT_EQ(0, memcmp(buf, m.data() + 2*sizeof(buf), sizeof(buf)));
+
+  // Scribble some '3' into the first page of the file, and verify that it looks
+  // the same in the memory mapping.
+  memset(buf, '3', sizeof(buf));
+  ASSERT_EQ(f.Write(0*sizeof(buf), buf, sizeof(buf)), (int)sizeof(buf));
+  ASSERT_EQ(0, memcmp(buf, m.data() + 0*sizeof(buf), sizeof(buf)));

[rmcilroy, 2015/09/17 17:17:44]

Are we sure that this atomic on all platforms we care about? it seems to me that
there might be a race where if the f.Write(...) gets buffered somewhere (and not
reflected in the mmap), but by the time the memcmp reads it the write is
reflected in the mmap. I'm not sure how to test for this though - maybe one more
test which only updates a single byte and checks that byte so there would be
less time between the initial write and the initial read of the mmap?

[Scott Hess - ex-Googler, 2015/09/17 21:14:37]

Ooooh, thanks for pointing this out, I hadn't thought of that issue.  What I'm
trying to test here is the relationship between the data passed to a system call
like pwrite(), and the memory map.  AFAICT both POSIX and Windows implement
base::File such that this tests the correct things as-is, but it would be
possible to have a base::File implementation over FILE or something, which
wouldn't be a correct test.

Unfortunately, the current implementation of base::File::Flush() is more like
fsync() than fflush(), which is _not_ what I want to test (AFAICT, this is the
problem with some platforms where SQLite found problems, the written data is
cached somewhere distinct until it is written to disk, at which point the memory
map will see it).

I'll revise the test to close the file after writing, which I think is likely to
imply something like fflush() but not imply anything like fsync().

+
+}
+
+}  // namespace sql