cc: Add GpuMemoryBufferHandle to TextureMailbox

content/common/cc_messages.h

Index: content/common/cc_messages.h
diff --git a/content/common/cc_messages.h b/content/common/cc_messages.h
index a3649191e09c885b2a7451b194eaacbbd98cad93..d7c7099198d1a938ee9414d1e31a7a91456beacf 100644
--- a/content/common/cc_messages.h
+++ b/content/common/cc_messages.h
@@ -282,6 +282,7 @@ IPC_STRUCT_TRAITS_BEGIN(cc::TransferableResource)
   IPC_STRUCT_TRAITS_MEMBER(mailbox_holder)
   IPC_STRUCT_TRAITS_MEMBER(read_lock_fences_enabled)
   IPC_STRUCT_TRAITS_MEMBER(is_software)
+  IPC_STRUCT_TRAITS_MEMBER(gpu_memory_buffer_handle)

[piman, 2016/05/03 23:40:49]

drive-by: 3 concerns here:
1- this means the browser has to trust handles coming from the renderer, this
seems dangerous? The renderer already asked the browser to create that handle,
so the browser should already knows about it, is there a way to refer to it
other than by handle?
2- when receiving the message on the browser side, it creates a new handle
there, which needs to be closed by someone - including in early outs of
RenderWidgetHostImpl::OnSwapCompositorFrame.
3- on the sender side, there is a potential for a race if the GMB is destroyed
on the compositor thread (or other thread) before the IO thread had a chance to
send the message (which is async, so you don't know when that happens) - Very
Bad Things happen in that case (potential for random handle to be sent and/or
closed instead). The typical pattern is to duplicate the handle and have the IPC
system close that after sending (see FileDescriptor::auto_close or
SharedMemoryHandle::OwnershipPassesToIPC())

   IPC_STRUCT_TRAITS_MEMBER(is_overlay_candidate)
 IPC_STRUCT_TRAITS_END()