Add RequestOSFileHandle as a private PPAPI

ppapi/cpp/private/file_io_private.cc

Index: ppapi/cpp/private/file_io_private.cc
diff --git a/ppapi/cpp/private/file_io_private.cc b/ppapi/cpp/private/file_io_private.cc
new file mode 100644
index 0000000000000000000000000000000000000000..8f21fa4986706e7531c388172ae9a4ef56366398
--- /dev/null
+++ b/ppapi/cpp/private/file_io_private.cc
@@ -0,0 +1,35 @@
+// Copyright (c) 2013 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 "ppapi/cpp/private/file_io_private.h"
+
+#include "ppapi/c/pp_errors.h"
+#include "ppapi/c/private/ppb_file_io_private.h"
+#include "ppapi/cpp/file_io.h"
+#include "ppapi/cpp/module_impl.h"
+
+namespace pp {
+
+namespace {
+
+template <> const char* interface_name<PPB_FileIO_Private>() {

[yzshen1, 2013/03/27 20:47:58]

nit: please append the version number explicitly. (PPB_FileIO_Private_0_1)

[hamaji, 2013/03/28 00:17:29]

Done.

+  return PPB_FILEIO_PRIVATE_INTERFACE_0_1;
+}
+
+}  // namespace
+
+FileIO_Private::FileIO_Private() {
+}
+
+int32_t FileIO_Private::GetOSFileHandle(const FileIO& file_io,
+                                        PP_FileHandle* result_handle,

[yzshen1, 2013/03/27 20:47:58]

Because usually CompletionCallback is generated by a callback factory, which
guarantees the callback is not called if the factory goes away.

It makes managing the memory of output parameter quite painful. (When/where can
I delete the memory allocated for |result_handle|?) Usually we will use
CompletionCallbackWithOutput<> to let the callback manage the memory.

Moreover, we have one more issue here: if cc is not called, but the
PP_FileHandle is set, we leak handles. Two ways that I can think of:
- Design something like PassPlatformFile. Or
- Make changes to completion_callback_factory and output_traits: change to not
call Traits::StorageToPluginArg() if the CompletionCallback won't be run, and
change traits classes to do cleanup in destructor.

The first approach seems simpler.
In that case you will need CompletionCallbackWithOutput<PassFileHandle>.

(At the C level, we don't have this problem, because if a function is run
asynchronously, PP_CompletionCallback will be called for sure.)

[hamaji, 2013/03/28 00:17:29]

I tried to address this comment, but it turned out this is a bit tough, at least
for me. One critical issue is that TestCompletionCallbackWithOutput isn't
working for POD type. This class expects
pp::CompletionCallbackWithOutput<OutputT>::OutputStorageType has output(), but
GenericCallbackOutputTraits::StorageType is T. I think this should be something
like GenericOutputAdapterWithStorage like ArrayOutputAdapterWithStorage.

So, can I leave this with a TODO comment for now? We'll use C interface
meanwhile. If it's OK, I'll file a bug for this issue. Could you tell me the
appropriate way to file a bug for pepper-team?

[yzshen1, 2013/03/28 20:59:49]

I am not sure I understand the issue here correctly. But I think you will need a
specialization of output traits class which has a storage class PassFileHandle
and has the API arg type PP_FileHandle.

I am okay to make it a TODO. Please label the bug with Plugins-Pepper-SDK.

[hamaji, 2013/03/28 21:37:15]

Yeah, I think we need something like it. Filed two bugs:

http://crbug.com/224741
http://crbug.com/224745

+                                        const CompletionCallback& cc) {
+  *result_handle = PP_kInvalidFileHandle;
+  if (has_interface<PPB_FileIO_Private>())
+    return get_interface<PPB_FileIO_Private>()->GetOSFileHandle(
+        file_io.pp_resource(), result_handle, cc.pp_completion_callback());
+  return cc.MayForce(PP_ERROR_NOINTERFACE);
+}
+
+}  // namespace pp