[BlobAsync] Patch 4: Browser Classes & Logic.

storage/browser/blob/blob_async_transport_strategy.h

Index: storage/browser/blob/blob_async_transport_strategy.h
diff --git a/storage/browser/blob/blob_async_transport_strategy.h b/storage/browser/blob/blob_async_transport_strategy.h
new file mode 100644
index 0000000000000000000000000000000000000000..7b7fe114aa29c00bd17f43da744f0bf4a9b04044
--- /dev/null
+++ b/storage/browser/blob/blob_async_transport_strategy.h
@@ -0,0 +1,129 @@
+// Copyright 2015 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 STORAGE_BROWSER_BLOB_BLOB_ASYNC_TRANSPORT_STRATEGY_H_
+#define STORAGE_BROWSER_BLOB_BLOB_ASYNC_TRANSPORT_STRATEGY_H_
+
+#include <map>
+#include <vector>
+
+#include "base/macros.h"
+#include "base/memory/scoped_ptr.h"
+#include "storage/browser/blob/blob_data_builder.h"
+#include "storage/browser/storage_browser_export.h"
+#include "storage/common/blob_storage/blob_item_bytes_request.h"
+#include "storage/common/data_element.h"
+
+namespace storage {
+
+// This class computes and stores the strategy for asynchronously transporting
+// memory from the renderer to the browser. We take memory constraints of our
+// system and the description of a blob, and figure out:
+// 1) How to store the blob data in the browser process: in memory or on disk.
+// 2) How to transport the data from the renderer: ipc payload, shared memory,
+//    or file handles.
+// We then generate data requests for that blob's memory and seed a
+// BlobDataBuilder for storing that data.
+//
+// Note: This class does not compute requests by using the 'shortcut' method,
+//       where the data is already present in the blob description, and will
+//       always give the caller the full strategy for requesting all data from
+//       the renderer.
+class STORAGE_EXPORT BlobAsyncTransportStrategy {
+ public:
+  enum Error {
+    ERROR_NONE = 0,
+    ERROR_TOO_LARGE,  // This item can't fit in disk or memory
+    ERROR_INVALID_PARAMS
+  };
+
+  struct RendererMemoryItemRequest {
+    RendererMemoryItemRequest();
+    // This is the index of the item in the builder on the browser side.
+    size_t browser_item_index;
+    // Note: For files this offset should always be 0, as the file offset in
+    //       segmentation is handled by the handle_offset in the message.  This
+    //       offset is used for populating a chunk when the data comes back to
+    //       the browser.
+    size_t browser_item_offset;
+    BlobItemBytesRequest message;
+    bool received;
+  };
+
+  BlobAsyncTransportStrategy();
+  virtual ~BlobAsyncTransportStrategy();
+
+  // This call does the computation to create the requests and builder for the
+  // blob given the memory constraints and blob description. |memory_available|
+  // is the total amount of memory we can offer for storing blobs.
+  // This method can only be called once.
+  void Initialize(size_t max_ipc_memory_size,
+                  size_t max_shared_memory_size,
+                  uint64_t max_file_size,
+                  uint64_t disk_space_left,
+                  size_t memory_available,
+                  const std::string& uuid,
+                  const std::vector<DataElement>& blob_item_infos);
+
+  // The sizes of the file handles being used (by handle index) in the async
+  // operation.
+  const std::vector<uint64_t>& file_handle_sizes() const {
+    return file_handle_sizes_;
+  }
+
+  // The sizes of the shared memory handles being used (by handle index) in the
+  // async operation.
+  const std::vector<size_t>& shared_memory_handle_sizes() const {
+    return shared_memory_handle_sizes_;
+  }
+
+  // The requests for memory, segmented as described above, along with their
+  // destination browser indexes and offsets.
+  const std::vector<RendererMemoryItemRequest>& requests() const {
+    return requests_;
+  }
+
+  // Marks the request at the given request number as recieved.
+  void MarkRequestAsReceived(size_t request_num) {
+    DCHECK_LT(request_num, requests_.size());
+    requests_[request_num].received = true;
+  }
+
+  // A BlobDataBuilder which can be used to construct the Blob in the
+  // BlobStorageContext object after:
+  // * The bytes items from AppendFutureData are populated by
+  //   PopulateFutureData.
+  // * The temporary files from AppendFutureFile are populated by
+  //   PopulateFutureFile.
+  BlobDataBuilder* blob_builder() { return builder_.get(); }
+
+  // The total bytes size of memory items in the blob.
+  uint64_t total_bytes_size() const { return total_bytes_size_; }
+
+  Error error() const { return error_; }
+
+  static bool ShouldBeShortcut(const std::vector<DataElement>& items,
+                               size_t memory_available);
+
+ private:
+  template <typename SizeType>
+  static void ComputeHandleSizes(SizeType total_memory_size,
+                                 SizeType max_segment_size,
+                                 std::vector<SizeType>* segment_sizes);
+
+  Error error_;
+
+  std::vector<uint64_t> file_handle_sizes_;

[michaeln, 2015/11/25 23:34:54]

Might be more trouble than its worth to have the two vectors be of two different
types? We get to decide the constraints, the max_file_size param could be
expressed in terms of size_t so a vector<size_t> would be fine. Could make for a
smaller binary too since no template expansion would be involved.

[dmurph, 2015/11/26 00:37:07]

I don't see why we need to add that restriction, it's not like we have a ton of
template expansions. Just two.  And this is correct forever! What about the
files that need to be > size_t big? Then again, 256k is enough for anybody.

[michaeln, 2015/11/30 21:07:26]

Since the source of the data for these files is blocks of memory in the renderer
process is size_t all the range that would ever be needed?

256k?

[dmurph, 2015/11/30 21:33:28]

It was a joke about Bill Gates haha.

I was thinking about if someone had one large array with a ton of memory and
then passed that array many times. 

[michaeln, 2015/11/30 21:57:19]

I guess its true that crazy api usage can describe a large amount of memory, but
what if we say max_file_size_ is < numeric_limit<size_t>::max(), would the blob
system ever try to create a file larger than that?

+  std::vector<size_t> shared_memory_handle_sizes_;
+
+  uint64_t total_bytes_size_;
+  std::vector<RendererMemoryItemRequest> requests_;
+  scoped_ptr<BlobDataBuilder> builder_;
+
+  DISALLOW_COPY_AND_ASSIGN(BlobAsyncTransportStrategy);
+};
+
+}  // namespace storage
+
+#endif  // STORAGE_BROWSER_BLOB_BLOB_ASYNC_TRANSPORT_STRATEGY_H_