Implements JS bindings for mojo shared buffer.

third_party/WebKit/Source/core/mojo/MojoHandle.h

Index: third_party/WebKit/Source/core/mojo/MojoHandle.h
diff --git a/third_party/WebKit/Source/core/mojo/MojoHandle.h b/third_party/WebKit/Source/core/mojo/MojoHandle.h
index 78fa9138b91b48b5c6a4a888a89e79b86c7a4235..b822f59648f654468ab199d17c71a0bdd85ff72b 100644
--- a/third_party/WebKit/Source/core/mojo/MojoHandle.h
+++ b/third_party/WebKit/Source/core/mojo/MojoHandle.h
@@ -11,7 +11,10 @@
 namespace blink {
 
 class ArrayBufferOrArrayBufferView;
+class MojoCloneBufferHandleFlags;
+class MojoCreateSharedBufferResult;
 class MojoHandleSignals;
+class MojoMapBufferResult;
 class MojoReadMessageFlags;
 class MojoReadMessageResult;
 class MojoWatchCallback;
@@ -29,10 +32,16 @@ class MojoHandle final : public GarbageCollectedFinalized<MojoHandle>,
   MojoWatcher* watch(ScriptState*,
                      const MojoHandleSignals&,
                      MojoWatchCallback*);
+
+  // MessagePipe handle.
   MojoResult writeMessage(ArrayBufferOrArrayBufferView&,
                           const HeapVector<Member<MojoHandle>>&);
   void readMessage(const MojoReadMessageFlags&, MojoReadMessageResult&);
 
+  // SharedBuffer handle.
+  void mapBuffer(unsigned offset, unsigned numBytes, MojoMapBufferResult&);

[yzshen1, 2017/03/01 23:11:46]

Do we also need a way to explicitly release the mapping, instead of waiting for
the JS object to be garbage-collected? Just like we have a close() method for
mojo handle.

[jbroman, 2017/03/01 23:29:37]

+1, this is probably a good thing to have. (I thought it was there in a previous
CL; I didn't mean that it had to be removed. Just that GC should suffice if
script doesn't unmap it first.)

[alokp, 2017/03/01 23:58:34]

I am not sure what the usecase for unmap would be though. Handle::close makes
sense because this is also a mechanism to trigger a connection error on the
other end at a predictable time.

Mapped shared buffer OTOH owns its own ArrayBuffer. Unmap is purely a resource
destruction mechanism with no side effect. Adding Unmap also makes the API
clunky because you need to create wrapper for ArrayBuffer.

That said, I do not feel strongly about this. I can be easily convinced
otherwise.

[yzshen1, 2017/03/02 17:41:08]

Because the mappings holds the underlying shared memory alive, it seems nice to
me to be able to explicitly release the resource if the user wants to.

I don't feel very strongly either. I am fine to add it later when/if we see the
need.

+  void clone(const MojoCloneBufferHandleFlags&, MojoCreateSharedBufferResult&);

[yzshen1, 2017/03/01 23:11:46]

Does it make sense to make the names more consistent with the C API:
duplicateBufferHandle / MojoDuplicateBufferHandleFlags?

[alokp, 2017/03/01 23:58:34]

Please see my other comment. I am happy to change it to duplicate if you like it
better.

+
   DEFINE_INLINE_TRACE() {}
 
  private: