Implements JS bindings for mojo shared buffer.

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

 // Copyright 2017 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 MojoHandle_h
 #define MojoHandle_h
 
 #include "bindings/core/v8/ScriptWrappable.h"
 #include "mojo/public/cpp/system/core.h"
 
 namespace blink {
 
 class ArrayBufferOrArrayBufferView;
+class MojoCloneBufferHandleFlags;
+class MojoCreateSharedBufferResult;
 class MojoHandleSignals;
+class MojoMapBufferResult;
 class MojoReadMessageFlags;
 class MojoReadMessageResult;
 class MojoWatchCallback;
 class MojoWatcher;
 class ScriptState;
 
 class MojoHandle final : public GarbageCollectedFinalized<MojoHandle>,
                          public ScriptWrappable {
   DEFINE_WRAPPERTYPEINFO();
 
  public:
   CORE_EXPORT static MojoHandle* create(mojo::ScopedHandle);
 
   void close();
   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:
   explicit MojoHandle(mojo::ScopedHandle);
 
   mojo::ScopedHandle m_handle;
 };
 
 }  // namespace blink
 
 #endif  // MojoHandle_h