Lazily allocate the holder in mojo::internal::SharedData<>.

Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=569694
Committed: https://crrev.com/b3057bedfb2584157e5e0da9a4936c2c80baf72c
Cr-Commit-Position: refs/heads/master@{#365764}

[Anand Mistry (off Chromium), 2015-12-16 01:51:37]

Description was changed from

==========
Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=545228
==========

to

==========
Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=569694
==========

[Anand Mistry (off Chromium), 2015-12-16 01:54:37]

amistry@chromium.org changed reviewers:
+ yzshen@chromium.org

[Anand Mistry (off Chromium), 2015-12-16 01:54:38]

The complexity in this change is because of the behaviour of SharedData<>. If
you create an empty SharedData, and then copy it into another, the two share the
same empty state, and changing one will affect the other.

[yzshen1, 2015-12-17 01:14:59]

LGTM

Eventually I think we will want to replace/reimplement this with some base/
utility class. But we can worry about that later.

[yzshen1, 2015-12-17 01:20:23]

On 2015/12/17 01:14:59, yzshen1 (OOO till new year) wrote:
> LGTM
> 
> Eventually I think we will want to replace/reimplement this with some base/
> utility class. But we can worry about that later.

Oh, forgot to mention, please add a comment in the code explaining why it is
needed to be implemented this way. (basically copying your CL description into
the code)

[Anand Mistry (off Chromium), 2015-12-17 04:37:06]

The CQ bit was checked by amistry@chromium.org

[Anand Mistry (off Chromium), 2015-12-17 04:37:06]

The patchset sent to the CQ was uploaded after l-g-t-m from yzshen@chromium.org
Link to the patchset: https://codereview.chromium.org/1512223002/#ps20001
(title: "Add comment.")

[commit-bot: I haz the power, 2015-12-17 04:38:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1512223002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1512223002/20001

[commit-bot: I haz the power, 2015-12-17 05:41:15]

Description was changed from

==========
Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=569694
==========

to

==========
Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=569694
==========

[commit-bot: I haz the power, 2015-12-17 05:41:16]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-12-17 05:42:20]

Description was changed from

==========
Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=569694
==========

to

==========
Lazily allocate the holder in mojo::internal::SharedData<>.

This makes it possible to create a SharedData on one thread, but
initialise it on another. This solves the issue of null mojo::Callbacks
being bound to the creation thread, preventing them from being assigned
on another (i.e. such as in uses of Binding<>).

BUG=569694

Committed: https://crrev.com/b3057bedfb2584157e5e0da9a4936c2c80baf72c
Cr-Commit-Position: refs/heads/master@{#365764}
==========

[commit-bot: I haz the power, 2015-12-17 05:42:21]

Patchset 2 (id:??) landed as
https://crrev.com/b3057bedfb2584157e5e0da9a4936c2c80baf72c
Cr-Commit-Position: refs/heads/master@{#365764}