Implements JS bindings for mojo data pipe.

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

 // 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.
 
 #include "core/mojo/MojoHandle.h"
 
 #include "bindings/core/v8/ArrayBufferOrArrayBufferView.h"
 #include "bindings/core/v8/ScriptState.h"
 #include "core/dom/DOMArrayBuffer.h"
 #include "core/dom/DOMArrayBufferView.h"
 #include "core/mojo/MojoCreateSharedBufferResult.h"
 #include "core/mojo/MojoDuplicateBufferHandleOptions.h"
 #include "core/mojo/MojoMapBufferResult.h"
+#include "core/mojo/MojoReadDataFlags.h"
+#include "core/mojo/MojoReadDataResult.h"
 #include "core/mojo/MojoReadMessageFlags.h"
 #include "core/mojo/MojoReadMessageResult.h"
 #include "core/mojo/MojoWatcher.h"
+#include "core/mojo/MojoWriteDataFlags.h"
+#include "core/mojo/MojoWriteDataResult.h"
 
 // Mojo messages typically do not contain many handles. In fact most
 // messages do not contain any handle. An inline capacity of 4 should avoid
 // heap allocation in vast majority of cases.
 static const size_t kHandleVectorInlineCapacity = 4;
 
 namespace blink {
 
 MojoHandle* MojoHandle::create(mojo::ScopedHandle handle) {
   return new MojoHandle(std::move(handle));
@@ skipping 61 matching lines @@
   for (size_t i = 0; i < numHandles; ++i) {
     handles[i] =
         MojoHandle::create(mojo::MakeScopedHandle(mojo::Handle(rawHandles[i])));
   }
 
   resultDict.setResult(result);
   resultDict.setBuffer(buffer);
   resultDict.setHandles(handles);
 }
 
+void MojoHandle::writeData(ArrayBufferOrArrayBufferView& buffer,
+                           const MojoWriteDataFlags& flagsDict,
+                           MojoWriteDataResult& resultDict) {
+  ::MojoWriteDataFlags flags = MOJO_WRITE_DATA_FLAG_NONE;
+  if (flagsDict.allOrNone())
+    flags |= MOJO_WRITE_DATA_FLAG_ALL_OR_NONE;
+
+  const void* elements = nullptr;
+  uint32_t numBytes = 0;
+  if (buffer.isArrayBuffer()) {
+    DOMArrayBuffer* array = buffer.getAsArrayBuffer();
+    elements = array->data();
+    numBytes = array->byteLength();
+  } else {
+    DOMArrayBufferView* view = buffer.getAsArrayBufferView();
+    elements = view->baseAddress();
+    numBytes = view->byteLength();
+  }
+
+  MojoResult result =
+      MojoWriteData(m_handle->value(), elements, &numBytes, flags);
+  resultDict.setResult(result);
+  resultDict.setNumBytes(numBytes);
+}
+
+void MojoHandle::readData(const MojoReadDataFlags& flagsDict,
+                          MojoReadDataResult& resultDict) {
+  // This version of readData can only be used for querying.
+  if (!flagsDict.query()) {
+    resultDict.setResult(MOJO_RESULT_INVALID_ARGUMENT);
+    return;
+  }
+
+  uint32_t numBytes = 0;
+  MojoResult result = MojoReadData(m_handle->value(), nullptr, &numBytes,
+                                   MOJO_READ_DATA_FLAG_QUERY);
+  resultDict.setResult(result);
+  resultDict.setNumBytes(numBytes);
+}
+
+void MojoHandle::readData(const MojoReadDataFlags& flagsDict,
+                          unsigned numBytes,
+                          MojoReadDataResult& resultDict) {
+  // This version of readData can only be used for discarding.
+  if (!flagsDict.discard()) {
+    resultDict.setResult(MOJO_RESULT_INVALID_ARGUMENT);
+    return;
+  }
+
+  ::MojoReadDataFlags flags = MOJO_READ_DATA_FLAG_DISCARD;
+  if (flagsDict.allOrNone())
+    flags |= MOJO_READ_DATA_FLAG_ALL_OR_NONE;
+
+  MojoResult result =
+      MojoReadData(m_handle->value(), nullptr, &numBytes, flags);
+  resultDict.setResult(result);
+  resultDict.setNumBytes(numBytes);
+}
+
+void MojoHandle::readData(const MojoReadDataFlags& flagsDict,
+                          unsigned numBytes,

[jbroman, 2017/03/07 16:01:44]

Any reason for the disparity between read/write, where read requires the caller
to supply the number of bytes to be read, but write infers it from the size of
the buffer source? I could see arguments for either approach.

[alokp, 2017/03/07 19:34:20]

My reasoning for not having numBytes on write was because to be really useful,
we would need to also add an offset. But since it is trivial to create a
DataView that supports both - offset and numBytes - it is not necessary.

I could get rid of numBytes from readData now that it is separate from
discardData if that would be more preferable.

[jbroman, 2017/03/07 20:31:47]

Mild preference for that (for simplicity, and consistent with the Java
bindings), but I don't feel strongly at all.

[alokp, 2017/03/07 20:49:31]

Done.

+                          ArrayBufferOrArrayBufferView& buffer,

[yzshen1, 2017/03/07 17:56:39]

[just to double check] Is it because having |buffer| param (instead of making it
a return value) enables users to read data into a specified position of a
pre-allocated, bigger buffer?

[alokp, 2017/03/07 19:34:20]

Right. I think a common usage pattern would be to reuse an ArrayBuffer to read
data as it becomes available. Creating an ArrayBuffer as done by the current
implementation is wasteful IMO.

+                          MojoReadDataResult& resultDict) {
+  // TODO(alokp): Validate options.
+
+  // This version of readData can only be used for reading and peeking.
+  ::MojoReadDataFlags flags = MOJO_READ_DATA_FLAG_NONE;
+  if (flagsDict.allOrNone())
+    flags |= MOJO_READ_DATA_FLAG_ALL_OR_NONE;
+  if (flagsDict.peek())
+    flags |= MOJO_READ_DATA_FLAG_PEEK;
+
+  void* elements = nullptr;
+  unsigned bufferLength = 0;
+  if (buffer.isArrayBuffer()) {
+    DOMArrayBuffer* array = buffer.getAsArrayBuffer();
+    elements = array->data();
+    bufferLength = array->byteLength();
+  } else {
+    DOMArrayBufferView* view = buffer.getAsArrayBufferView();
+    elements = view->baseAddress();
+    bufferLength = view->byteLength();
+  }
+  numBytes = std::min(bufferLength, numBytes);

[jbroman, 2017/03/07 16:01:44]

Isn't it always an error on the part of the programmer to request |numBytes|
bytes and then supply a buffer smaller than |numBytes|? I'd expect an exception
to be thrown here, rather than silently reading less data.

[yzshen1, 2017/03/07 17:56:39]

We could return INVALID_ARGUMENT in this case, considering that we always use
result code instead of exception. WDYT?

[alokp, 2017/03/07 19:34:20]

Done.

+
+  MojoResult result =
+      MojoReadData(m_handle->value(), elements, &numBytes, flags);
+  resultDict.setResult(result);
+  resultDict.setResult(numBytes);
+}
+
 void MojoHandle::mapBuffer(unsigned offset,
                            unsigned numBytes,
                            MojoMapBufferResult& resultDict) {
   void* data = nullptr;
   MojoResult result = MojoMapBuffer(m_handle->value(), offset, numBytes, &data,
                                     MOJO_MAP_BUFFER_FLAG_NONE);
   resultDict.setResult(result);
   if (result == MOJO_RESULT_OK) {
     WTF::ArrayBufferContents::DataHandle dataHandle(data, [](void* buffer) {
       MojoResult result = MojoUnmapBuffer(buffer);
@@ skipping 16 matching lines @@
   mojo::Handle handle;
   MojoResult result = MojoDuplicateBufferHandle(m_handle->value(), &options,
                                                 handle.mutable_value());
   resultDict.setResult(result);
   if (result == MOJO_RESULT_OK) {
     resultDict.setHandle(MojoHandle::create(mojo::MakeScopedHandle(handle)));
   }
 }
 
 }  // namespace blink