Cancel a task associated to TaskHandle when the TaskHandle is overridden

Cancel a task associated to TaskHandle when the TaskHandle is overridden

When a TaskHandle is overridden by another TaskHandle, the original
task should be cancelled, though the previous implementation of TaskRunner
unintentionally detach the old task without cancelling it.

This CL implements the move-assignment operator properly, so that the
assignment operation cancels old task.

Committed: https://crrev.com/0b5fe82535de96d22d0bd32704e0b3b57f6a07b7
Cr-Commit-Position: refs/heads/master@{#430579}

[tzik, 2016-11-07 08:43:57]

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

[commit-bot: I haz the power, 2016-11-07 08:44:05]

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

[tzik, 2016-11-07 08:45:12]

tzik@chromium.org changed reviewers:
+ haraken@chromium.org, hiroshige@chromium.org

[tzik, 2016-11-07 08:45:13]

PTAL

[haraken, 2016-11-07 10:06:49]

I asked a question related to this CL in
https://codereview.chromium.org/2478603003/

[commit-bot: I haz the power, 2016-11-07 10:26:32]

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

[commit-bot: I haz the power, 2016-11-07 10:26:33]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-11-08 08:32:12]

Discussed offline. LGTM.

[hiroshige, 2016-11-08 08:43:35]

lgtm

[tzik, 2016-11-08 09:15:38]

Logging the discussion:

> Hmm, we need to keep holding m_pendingEvent in order not to cancel the task...
> which seems error-prone to me; i.e., if developers forget to hold the task
> handle, the task will be unintentionally cancelled.
> 
> Would you help me understand why we wanted to adopt the cancel-on-destruction
> semantics for TaskHandles?

That is because all known use cases of the task cancellation are in
cancel-on-destruction semantics. So, the migration is easier on
cancel-on-destruction semantics.
If it turns out to be problematic, we can provide another class without
cancel-on-destruction.

[tzik, 2016-11-08 09:15:57]

The CQ bit was checked by tzik@chromium.org

[commit-bot: I haz the power, 2016-11-08 09:16:19]

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-11-08 11:38:54]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-08 11:40:57]

Description was changed from

==========
Cancel a task associated to TaskHandle when the TaskHandle is overridden

When a TaskHandle is overridden by another TaskHandle, the original
task should be cancelled, though the previous implementation of TaskRunner
unintentionally detach the old task without cancelling it.

This CL implements the move-assignment operator properly, so that the
assignment operation cancels old task.
==========

to

==========
Cancel a task associated to TaskHandle when the TaskHandle is overridden

When a TaskHandle is overridden by another TaskHandle, the original
task should be cancelled, though the previous implementation of TaskRunner
unintentionally detach the old task without cancelling it.

This CL implements the move-assignment operator properly, so that the
assignment operation cancels old task.

Committed: https://crrev.com/0b5fe82535de96d22d0bd32704e0b3b57f6a07b7
Cr-Commit-Position: refs/heads/master@{#430579}
==========

[commit-bot: I haz the power, 2016-11-08 11:40:58]

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