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..89a168f216e9751f255a34f5c29e307b6240351a
--- /dev/null
+++ b/content/common/shared_memory_seqlock_buffer.h
@@ -0,0 +1,38 @@
+// 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 device motion

[scottmg, 2013/06/24 23:24:38]

being that this is currently device motion specific, it has a pretty generic
name. or will the gamepad code be refactored to use it also?

[timvolodine, 2013/06/25 03:36:07]

Yes, the idea is to use this for the gamepad code as well in a separate patch
though.
I have modified the comments appropriately.

+// 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 {
+ public:
+  OneWriterSeqLock seqlock;
+
+  // This boolean is used to indicate the state of the buffer,
+  // it is not used for locking.
+  bool is_ready_for_read;

[scottmg, 2013/06/24 23:24:38]

(unrelated to looking at gamepad changes, but) this field sort of scares me.
should the "data is valid" field not be a member of the templated contained
Data?

[timvolodine, 2013/06/25 03:36:07]

ok, I've moved this field to WebDeviceMotionData, since it is actually Device
Motion specific.
It seems reasonable to assume that the generalized buffer should only contain a
lock and data. That way it will also be applicable to gamepad.

+};
+
+template<class Data>
+class SharedMemorySeqLockBuffer : public SharedMemorySeqLockBufferBase {

[darin (slow to review), 2013/06/24 23:40:34]

nit: Since there are no methods here, it seems like there isn't much of a
benefit to factoring out a non-template *Base class here.

[timvolodine, 2013/06/25 03:36:07]

The base buffer class is used by the shared_memory_seqlock_reader_base which is
a non-templated class, hence the need for a non-templated buffer class.

+ public:
+  Data data;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_COMMON_SHARED_MEMORY_SEQLOCK_BUFFER_H_