Add gpu::MailboxHolder to hold state for a gpu::Mailbox

Add gpu::MailboxHolder to hold state for a gpu::Mailbox

gpu::Mailbox by itself can hold only a texture id, but in common usage it comes
with texture target and syncpoint information for cross-context sharing.  To
reduce repetition of this pattern, gpu::MailboxHolder holds:

* a gpu::Mailbox
* a GL texture target
* a syncpoint index

Refactor other classes to use a gpu::MailboxHolder instead of separate
gpu::Mailbox and associated state.

Syncpoints are created with uint32 indices; make sure all uses of syncpoints
use the appropriate type.

BUG=None
TEST=local build, unittests on CrOS snow, desktop Linux
TBR=piman@chromium.org, enn@chromium.orge, cevans@chromium.org, scherkus@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=248612

[sheu, 2014-01-28 00:31:05]

danakj@: PTAL at this again.  The relevant diff is the first patch against the
second, the rest are rebases.

As you'll recall, we discussed removing scoped_ptr from the callback, but I have
to add it back again because of the crash (and the revert) in crbug.com/336040.

[danakj, 2014-01-29 20:30:47]

Can you explain how the scoped_ptr solves the crash? Were things holding onto
the MailboxHolder* which was then destroyed by the VideoFrame? Would using a
const MailboxHolder& be any better?

[sheu, 2014-01-29 20:34:09]

On 2014/01/29 20:30:47, danakj wrote:
> Can you explain how the scoped_ptr solves the crash? Were things holding onto
> the MailboxHolder* which was then destroyed by the VideoFrame? Would using a
> const MailboxHolder& be any better?

For the purposes of doing the destruction of the MailboxHolder on the right
thread, the destruction callback run by the VideoFrame (which takes the
MailboxHolder argument) in some cases posts the actual destruction work to a
different thread.  The callback though is synchronous with the destructor of the
VideoFrame, so by the time the destruction work is run, the VideoFrame has
already been destroyed.

That's the crash.  Being able to pass ownership solves this.

[danakj, 2014-01-29 20:40:08]

On 2014/01/29 20:34:09, sheu wrote:
> On 2014/01/29 20:30:47, danakj wrote:
> > Can you explain how the scoped_ptr solves the crash? Were things holding
onto
> > the MailboxHolder* which was then destroyed by the VideoFrame? Would using a
> > const MailboxHolder& be any better?
> 
> For the purposes of doing the destruction of the MailboxHolder on the right
> thread, the destruction callback run by the VideoFrame (which takes the
> MailboxHolder argument) in some cases posts the actual destruction work to a
> different thread.  The callback though is synchronous with the destructor of
the
> VideoFrame, so by the time the destruction work is run, the VideoFrame has
> already been destroyed.
> 
> That's the crash.  Being able to pass ownership solves this.

Ah, I see. Cool. Then LGTM for scoped_ptr or passing by value.

[sheu, 2014-01-29 22:30:18]

This is a revert of a revert essentially.  Sending to CQ with TBRs.

[commit-bot: I haz the power, 2014-01-29 22:36:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sheu@chromium.org/132233041/260001

[commit-bot: I haz the power, 2014-01-29 23:04:01]

Retried try job too often on mac_rel for step(s) base_unittests, browser_tests,
interactive_ui_tests, net_unittests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[sheu, 2014-02-03 21:02:29]

The CQ bit was checked by sheu@chromium.org

[commit-bot: I haz the power, 2014-02-03 21:03:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sheu@chromium.org/132233041/550001

[commit-bot: I haz the power, 2014-02-03 23:39:53]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-02-03 23:39:55]

Change committed as 248612

[commit-bot: I haz the power, 2014-02-03 23:39:55]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-02-03 23:39:55]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-02-03 23:39:56]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-02-03 23:40:00]

CQ bit was unchecked on CL. Ignoring.