Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

TBR=ben@chromium.org
BUG=650318
Committed: https://crrev.com/7b67e033842715d4941d46e726df8ca18d94d768
Cr-Commit-Position: refs/heads/master@{#421179}

[fdoray, 2016-09-26 19:24:22]

Description was changed from

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

R=ben@chromium.org,grt@chromium.org
BUG=616447
==========

to

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

R=ben@chromium.org,grt@chromium.org
BUG=650318
==========

[fdoray, 2016-09-26 19:24:30]

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

[commit-bot: I haz the power, 2016-09-26 19:25:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[fdoray, 2016-09-26 19:25:47]

grt@: PTAL

I won't land this before I confirm that the Win10 bots are green.

[grt (UTC plus 2), 2016-09-26 19:52:36]

still lgtm. thanks.

[commit-bot: I haz the power, 2016-09-26 20:44:55]

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

[commit-bot: I haz the power, 2016-09-26 20:44:56]

Dry run: This issue passed the CQ dry run.

[fdoray, 2016-09-27 12:16:58]

The CQ bit was checked by fdoray@chromium.org

[fdoray, 2016-09-27 12:17:04]

The CQ bit was unchecked by fdoray@chromium.org

[fdoray, 2016-09-27 12:17:21]

Description was changed from

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

R=ben@chromium.org,grt@chromium.org
BUG=650318
==========

to

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

TBR=ben@chromium.org
BUG=650318
==========

[fdoray, 2016-09-27 12:18:09]

Thanks!

TBR ben@ for missing includes added to various files

[fdoray, 2016-09-27 12:18:15]

The CQ bit was checked by fdoray@chromium.org

[commit-bot: I haz the power, 2016-09-27 12:18:30]

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, 2016-09-27 12:23:54]

Description was changed from

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

TBR=ben@chromium.org
BUG=650318
==========

to

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

TBR=ben@chromium.org
BUG=650318
==========

[commit-bot: I haz the power, 2016-09-27 12:23:55]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-27 12:26:12]

Description was changed from

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

TBR=ben@chromium.org
BUG=650318
==========

to

==========
Remove MessageLoop::current() from base::win::ObjectWatcher (reland).

---
This is a reland of https://codereview.chromium.org/2125763003 which
was reverted because it broke the Win10 builder. It should not break
anything now that TestSimpleTaskRunner is thread-safe
(https://codereview.chromium.org/2296923003)
---

Why? The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads are migrated to
base/task_scheduler, tasks will no longer have access to a MessageLoop
but they will be able to get the current ThreadTaskRunnerHandle.

Before this CL, ObjectWatcher implemented
WillDestroyCurrentMessageLoop() to stop the watch when the
MessageLoop responsible for running the callback was destroyed.
This prevented the watch callback from being sent to a destroyed
MessageLoop.

Now that ObjectWatcher keeps a reference to a TaskRunner, this is
no longer required. The TaskRunner can't be deleted while there are
references to it. If the underlying MessageLoop has been deleted
when the watch callback is posted, the callback will simply not run.

Note that the watch will still be stopped when the ObjectWatcher is
deleted.

TBR=ben@chromium.org
BUG=650318

Committed: https://crrev.com/7b67e033842715d4941d46e726df8ca18d94d768
Cr-Commit-Position: refs/heads/master@{#421179}
==========

[commit-bot: I haz the power, 2016-09-27 12:26:13]

Patchset 1 (id:??) landed as
https://crrev.com/7b67e033842715d4941d46e726df8ca18d94d768
Cr-Commit-Position: refs/heads/master@{#421179}