[scheduler]: Fix a bug with non-nestable tasks.

[scheduler]: Fix a bug with non-nestable tasks.

Avoids a DCHECK in TaskQueueImpl::Task::enqueue_order() caused by
TaskIsOlderThanQueuedTasks being called on an empty task if the previous
task was a non-nestable task while the scheduler is running on a nested
message loop.

Committed: https://crrev.com/c0d31ab28e21c048f40584ace3b0a8aca5723c17
Cr-Commit-Position: refs/heads/master@{#343026}

[rmcilroy, 2015-08-12 11:39:09]

rmcilroy@chromium.org changed reviewers:
+ skyostil@chromium.org

[rmcilroy, 2015-08-12 11:39:09]

PTAL, thanks.

[rmcilroy, 2015-08-12 11:39:16]

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

[commit-bot: I haz the power, 2015-08-12 11:39:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1287003003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1287003003/1

[Sami, 2015-08-12 11:47:51]

https://codereview.chromium.org/1287003003/diff/1/components/scheduler/child/...
File components/scheduler/child/task_queue_manager.cc (right):

https://codereview.chromium.org/1287003003/diff/1/components/scheduler/child/...
components/scheduler/child/task_queue_manager.cc:307: *out_previous_task =
pending_task;
Hmm, should we just ignore out_previous_task if we decided to actually not run
it? It feels wrong if a non-nestable task will still cause a wakeup even though
we didn't actually run it. WDYT?

I guess one way would be to have this function return a tri-state enum to say
what it actually did.

[commit-bot: I haz the power, 2015-08-12 12:33:00]

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

[commit-bot: I haz the power, 2015-08-12 12:33:00]

Dry run: This issue passed the CQ dry run.

[rmcilroy, 2015-08-12 13:08:27]

https://codereview.chromium.org/1287003003/diff/1/components/scheduler/child/...
File components/scheduler/child/task_queue_manager.cc (right):

https://codereview.chromium.org/1287003003/diff/1/components/scheduler/child/...
components/scheduler/child/task_queue_manager.cc:307: *out_previous_task =
pending_task;
On 2015/08/12 11:47:51, Sami wrote:
> Hmm, should we just ignore out_previous_task if we decided to actually not run
> it? It feels wrong if a non-nestable task will still cause a wakeup even
though
> we didn't actually run it. WDYT?
> 
> I guess one way would be to have this function return a tri-state enum to say
> what it actually did.

As discussed offline, this might be our only chance to wake up an after wakeup
queue because we will never get notified when the non-nestable task gets run.
Add a comment as discussed.

[rmcilroy, 2015-08-12 13:16:10]

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

[commit-bot: I haz the power, 2015-08-12 13:16:16]

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

[commit-bot: I haz the power, 2015-08-12 14:01:48]

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

[commit-bot: I haz the power, 2015-08-12 14:01:49]

Dry run: This issue passed the CQ dry run.

[Sami, 2015-08-12 15:36:21]

lgtm. Thanks for the test too.

[rmcilroy, 2015-08-12 15:58:22]

The CQ bit was checked by rmcilroy@chromium.org

[commit-bot: I haz the power, 2015-08-12 15:58:27]

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

[commit-bot: I haz the power, 2015-08-12 16:02:43]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-08-12 16:03:18]

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

[rmcilroy, 2015-08-13 14:54:52]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1287333002/ by rmcilroy@chromium.org.

The reason for reverting is: Causing crashes on Mac.

BUG=520524.