Implement the content/renderer and content/browser part of the Device Motion API.

content/common/shared_memory_seqlock_buffer.h

Index: content/common/shared_memory_seqlock_buffer.h
diff --git a/content/common/shared_memory_seqlock_buffer.h b/content/common/shared_memory_seqlock_buffer.h
new file mode 100644
index 0000000000000000000000000000000000000000..63b9e52a9f93950dab1f3b765b6ae50b6e061bd4
--- /dev/null
+++ b/content/common/shared_memory_seqlock_buffer.h
@@ -0,0 +1,34 @@
+// Copyright (c) 2013 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.
+
+#ifndef CONTENT_COMMON_SHARED_MEMORY_SEQLOCK_BUFFER_H_
+#define CONTENT_COMMON_SHARED_MEMORY_SEQLOCK_BUFFER_H_
+
+#include "content/common/one_writer_seqlock.h"
+
+namespace content {
+
+// This structure is stored in shared memory that's shared between the browser
+// which does the hardware polling, and the consumers of the data,
+// i.e. the renderers. The performance characteristics are that
+// we want low latency (so would like to avoid explicit communication via IPC
+// between producer and consumer) and relatively large data size.
+//
+// Writer and reader operate on the same buffer assuming contention is low, and
+// contention is detected by using the associated SeqLock.
+
+class SharedMemorySeqLockBufferBase {

[darin (slow to review), 2013/06/27 17:33:26]

Why do we need to carve out a Base class in this case?  Since there aren't any
methods here, it seems reasonable to just give SharedMemorySeqLockBuffer<T> a
OneWriterSeqLock member.

It seems like the Gamepad buffer class could be trivially changed to be a
specialization of SharedMemorySeqLockBuffer<T>.  Why not just do that as part of
this CL?

[timvolodine, 2013/06/27 21:08:43]

ok, I've removed this base class and added an extra lock-parameter to
SharedMemorySeqLockReaderBase::FetchFromBuffer to keep it generic.

Regarding Gamepad I think this is best done in a separate CL. Gamepad buffer
uses "buffer" as a name for "data", so some renaming will need to happen
touching multiple files (thinking about fetchers and test files), which will
'pollute' this CL.

+ public:
+  OneWriterSeqLock seqlock;
+};
+
+template<class Data>
+class SharedMemorySeqLockBuffer : public SharedMemorySeqLockBufferBase {
+ public:
+  Data data;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_COMMON_SHARED_MEMORY_SEQLOCK_BUFFER_H_