Turn the utility process image decoder into a Mojo service.

chrome/utility/chrome_content_utility_client.h

 // Copyright (c) 2012 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 CHROME_UTILITY_CHROME_CONTENT_UTILITY_CLIENT_H_
 #define CHROME_UTILITY_CHROME_CONTENT_UTILITY_CLIENT_H_
 
 #include <set>
 #include <string>
 #include <vector>
@@ skipping 24 matching lines @@
   // Shared with extensions::ExtensionsHandler.
   static SkBitmap DecodeImage(const std::vector<unsigned char>& encoded_data,
                               bool shrink_to_fit);
   static void DecodeImageAndSend(const std::vector<unsigned char>& encoded_data,
                                  bool shrink_to_fit);
 
   static void set_max_ipc_message_size_for_test(int64_t max_message_size) {
     max_ipc_message_size_ = max_message_size;
   }
 
+  // Reference counting for Mojo services. A reference count is incremented when
+  // Mojo services are connected to, and decremented when the connection is
+  // destroyed. When the count reaches 0, this process is freed. The assumption
+  // is that multiple Mojo services can be connected to in the same utility
+  // process. This is a Mojo alternative to "batch mode" for Chrome IPC.
+  void MojoRef();

[sky, 2015/04/01 15:00:45]

Who is responsible for invoking these?

[Anand Mistry (off Chromium), 2015/04/02 04:29:45]

Added a blurb to describe this. At this point, I'm sure I want to refcount the
Mojo connections for establishing the lifetime of the utility process/thread.
However, the exact mechanism for doing so is something I'm still grappling with.
I added some templating to chrome_content_utility_client.cc which does it
implicitly based on a service implementation's lifetime, assuming a
StrongBinding<>. But I've also thought about doing it by passing a callback to
the service. I'm not sure about this yet.

[sky, 2015/04/02 17:20:10]

Having to explicitly invoke functions like this is error prone. Make it
consumers have to use a RAII class whose constructor does the Ref and destructor
the Unref.

[Anand Mistry (off Chromium), 2015/04/08 07:14:15]

On further thought, there are races with this kind of service tracking and
shutdown which can cause spurious failures at the consumers. For now, I think
it's best to leave this out and require the browser side to shut down the
utility process when connecting to Mojo-based services.

Also, if the utility process is untrusted, can we really trust it to shut itself
down?

+  void MojoUnref();
+
  private:
   // IPC message handlers.
   void OnUnpackWebResource(const std::string& resource_data);
   void OnDecodeImage(const std::vector<unsigned char>& encoded_data,
                      bool shrink_to_fit);
   void OnRobustJPEGDecodeImage(
       const std::vector<unsigned char>& encoded_data);
 
 #if defined(OS_CHROMEOS)
   void OnCreateZipFile(const base::FilePath& src_dir,
@@ skipping 27 matching lines @@
   typedef ScopedVector<UtilityMessageHandler> Handlers;
   Handlers handlers_;
 
   // Flag to enable whitelisting.
   bool filter_messages_;
   // A list of message_ids to filter.
   std::set<int> message_id_whitelist_;
   // Maximum IPC msg size (default to kMaximumMessageSize; override for testing)
   static int64_t max_ipc_message_size_;
 
+  int32_t mojo_service_ref_count_;
+
   DISALLOW_COPY_AND_ASSIGN(ChromeContentUtilityClient);
 };
 
 #endif  // CHROME_UTILITY_CHROME_CONTENT_UTILITY_CLIENT_H_