Replace deprecated base::NonThreadSafe in android_webview in favor of SequenceChecker.

Replace deprecated base::NonThreadSafe in android_webview in favor of SequenceChecker.

Note to crash team: This CL is a refactor and has no intended behavior change.

This change was scripted by https://crbug.com/676387#c8.

Note-worthy for the reviewer:
 * SequenceChecker enforces thread-safety but not thread-affinity!
   If the classes that were updated are thread-affine (use thread local
   storage or a third-party API that does) they should be migrated to
   ThreadChecker instead.
 * ~NonThreadSafe() used to implcitly check in its destructor
   ~Sequence/ThreadChecker() doesn't by design. To keep this CL a
   no-op, an explicit check was added to the destructor of migrated
   classes.
 * NonThreadSafe used to provide access to subclasses, as such
   the |sequence_checker_| member was made protected rather than
   private where necessary.

BUG=676387
This CL was uploaded by git cl split.

R=boliu@chromium.org

Review-Url: https://codereview.chromium.org/2909173002
Cr-Commit-Position: refs/heads/master@{#475631}
Committed: https://chromium.googlesource.com/chromium/src/+/4523afedd7271dcdd8a2d310e219ecb8c63fff63

[gab, 2017-05-30 02:35:49]

The CQ bit was checked by gab@chromium.org to run a CQ dry run

[gab, 2017-05-30 02:35:51]

Hi, this is an automated change made by https://crbug.com/676387#c8 and sharded
across directories for OWNERS.

No human has looked at this specific output yet, see cl description for things
to watch for.

If it LGTY, please CQ.

If it didn't pass CQ dry-run it may be a simple patch failure or an IWYU failure
from having this being a partial CL... please review anyways and a human will
look at the failure (and ping for re-review if anything major is required..). It
is known to compile all targets on Windows at r474679...  manual tweaks will
likely be required to smoothen things off, bear with me!

Thanks!
Gab

[commit-bot: I haz the power, 2017-05-30 02:35:59]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-30 03:07:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-30 03:07:31]

Dry run: This issue passed the CQ dry run.

[boliu, 2017-05-30 15:40:19]

I dunno about this one exactly. Depends on whether all the content stuff like
webcontents are going to be thread safe only or has thread affinity. On android
and I imagine on other platforms as well, UI is a specific thread, so I imagine
webcontents and such should have the stronger thread affinity?

[gab, 2017-05-30 18:30:38]

On 2017/05/30 15:40:19, boliu wrote:
> I dunno about this one exactly. Depends on whether all the content stuff like
> webcontents are going to be thread safe only or has thread affinity. On
android
> and I imagine on other platforms as well, UI is a specific thread, so I
imagine
> webcontents and such should have the stronger thread affinity?

If this specific class isn't thread-affine it shouldn't be marked as such. If
dependencies end up being thread-affine they'll mark themselves as such and this
class will transitively be "thread-affine", but at least be only marking
thread-affinity on the classes that truly are, if we ever wonder why something
can't run on a sequence we only have to look at the specific classes that are
still marked thread-affine instead of all of those that are just because they
decided to inherit their parent's property.

[boliu, 2017-05-30 18:34:07]

On 2017/05/30 18:30:38, gab wrote:
> On 2017/05/30 15:40:19, boliu wrote:
> > I dunno about this one exactly. Depends on whether all the content stuff
like
> > webcontents are going to be thread safe only or has thread affinity. On
> android
> > and I imagine on other platforms as well, UI is a specific thread, so I
> imagine
> > webcontents and such should have the stronger thread affinity?
> 
> If this specific class isn't thread-affine it shouldn't be marked as such. If
> dependencies end up being thread-affine they'll mark themselves as such and
this
> class will transitively be "thread-affine", but at least be only marking
> thread-affinity on the classes that truly are, if we ever wonder why something
> can't run on a sequence we only have to look at the specific classes that are
> still marked thread-affine instead of all of those that are just because they
> decided to inherit their parent's property.

sure, lgtm

[boliu, 2017-05-30 19:10:12]

The CQ bit was checked by boliu@chromium.org

[commit-bot: I haz the power, 2017-05-30 19:11:25]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-30 19:43:21]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1496171412522540, "parent_rev":
"aa57febde88dfcd155767be89e9658c6158b350c", "commit_rev":
"4523afedd7271dcdd8a2d310e219ecb8c63fff63"}

[commit-bot: I haz the power, 2017-05-30 19:43:30]

Description was changed from

==========
Replace deprecated base::NonThreadSafe in android_webview in favor of
SequenceChecker.

Note to crash team: This CL is a refactor and has no intended behavior change.

This change was scripted by https://crbug.com/676387#c8.

Note-worthy for the reviewer:
 * SequenceChecker enforces thread-safety but not thread-affinity!
   If the classes that were updated are thread-affine (use thread local
   storage or a third-party API that does) they should be migrated to
   ThreadChecker instead.
 * ~NonThreadSafe() used to implcitly check in its destructor
   ~Sequence/ThreadChecker() doesn't by design. To keep this CL a
   no-op, an explicit check was added to the destructor of migrated
   classes.
 * NonThreadSafe used to provide access to subclasses, as such
   the |sequence_checker_| member was made protected rather than
   private where necessary.

BUG=676387
This CL was uploaded by git cl split.

R=boliu@chromium.org
==========

to

==========
Replace deprecated base::NonThreadSafe in android_webview in favor of
SequenceChecker.

Note to crash team: This CL is a refactor and has no intended behavior change.

This change was scripted by https://crbug.com/676387#c8.

Note-worthy for the reviewer:
 * SequenceChecker enforces thread-safety but not thread-affinity!
   If the classes that were updated are thread-affine (use thread local
   storage or a third-party API that does) they should be migrated to
   ThreadChecker instead.
 * ~NonThreadSafe() used to implcitly check in its destructor
   ~Sequence/ThreadChecker() doesn't by design. To keep this CL a
   no-op, an explicit check was added to the destructor of migrated
   classes.
 * NonThreadSafe used to provide access to subclasses, as such
   the |sequence_checker_| member was made protected rather than
   private where necessary.

BUG=676387
This CL was uploaded by git cl split.

R=boliu@chromium.org

Review-Url: https://codereview.chromium.org/2909173002
Cr-Commit-Position: refs/heads/master@{#475631}
Committed:
https://chromium.googlesource.com/chromium/src/+/4523afedd7271dcdd8a2d310e219...
==========

[commit-bot: I haz the power, 2017-05-30 19:43:31]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/4523afedd7271dcdd8a2d310e219...