Implement PostDelayedTaskAt for guaranteed timer ordering

Implement PostDelayedTaskAt for guaranteed timer ordering

This patch implements a new method for posting delayed tasks:
PostDelayedTaskAt(). In contrast to PostDelayedTask(), this API accepts
the desired run time as an absolute time stamp instead of a delta from
the current time. This makes it possible for Blink to post several
aligned timers to the same desired run time and have the timers execute
in their posted order.

BUG=508279
Committed: https://crrev.com/2a96102e57a45f9c87187fb2b4f35c3cdba6153a
Cr-Commit-Position: refs/heads/master@{#339024}

[Sami, 2015-07-15 18:10:48]

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

[Sami, 2015-07-15 18:11:16]

PTAL.

[alex clarke (OOO till 29th), 2015-07-16 09:29:00]

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
File components/scheduler/child/null_task_queue.h (right):

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/null_task_queue.h:13: class SCHEDULER_EXPORT
NullTaskQueue : public TaskQueue {
The .cc file for this seems to be missing.

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
File components/scheduler/child/task_queue_manager.cc (right):

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/task_queue_manager.cc:117: base::TimeDelta delay,
It feels a bit weird having both a delay and a desired_run_time.

How about passing in LazyNow and desired_run_time, and have PostDelayedTask &
PostNonNestableDelayedTask do the computation for desired_run_time?

If desired_run_time was null then PostDelayedTaskImpl would enqueue the task
immediately.

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/task_queue_manager.cc:226:
pending_task.delayed_run_time = std::max(now, desired_run_time);
Should we just enqueue the task if desired runtime is in the past?

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
File components/scheduler/child/web_scheduler_impl.h (right):

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/web_scheduler_impl.h:48: double monotonicTime);
Is monotonicTime the right name for this parameter?

[Sami, 2015-07-16 12:19:32]

Comments addressed, PTAL.

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
File components/scheduler/child/null_task_queue.h (right):

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/null_task_queue.h:13: class SCHEDULER_EXPORT
NullTaskQueue : public TaskQueue {
On 2015/07/16 09:29:00, alexclarke1 wrote:
> The .cc file for this seems to be missing.

Welp I guess that explains the failing try jobs. Thanks :)

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
File components/scheduler/child/task_queue_manager.cc (right):

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/task_queue_manager.cc:117: base::TimeDelta delay,
On 2015/07/16 09:29:00, alexclarke1 wrote:
> It feels a bit weird having both a delay and a desired_run_time.
> 
> How about passing in LazyNow and desired_run_time, and have PostDelayedTask &
> PostNonNestableDelayedTask do the computation for desired_run_time?
> 
> If desired_run_time was null then PostDelayedTaskImpl would enqueue the task
> immediately.

Yep I struggled with this interface a bit. The locking makes it a little
inconvenient, but let me give this another shot.

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/task_queue_manager.cc:226:
pending_task.delayed_run_time = std::max(now, desired_run_time);
On 2015/07/16 09:29:00, alexclarke1 wrote:
> Should we just enqueue the task if desired runtime is in the past?

I think that might change the ordering. For example let's say it's t=0 and we
get two tasks targeting t=1. If we noticed that it's already t=2 when the second
task comes in, it would skip the delayed task queue and run ahead of the first
task.

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
File components/scheduler/child/web_scheduler_impl.h (right):

https://codereview.chromium.org/1223163006/diff/40001/components/scheduler/ch...
components/scheduler/child/web_scheduler_impl.h:48: double monotonicTime);
On 2015/07/16 09:29:00, alexclarke1 wrote:
> Is monotonicTime the right name for this parameter?

I did some grepping and that's what most of Blink seems to be using. It's not
the greatest name but I think we should be consistent. (BTW the meaning is
documented better over on the Blink side.)

[alex clarke (OOO till 29th), 2015-07-16 12:23:27]

lgtm

[Sami, 2015-07-16 12:24:45]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2015-07-16 12:25:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1223163006/80001

[commit-bot: I haz the power, 2015-07-16 12:29:29]

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

[commit-bot: I haz the power, 2015-07-16 12:29:31]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

(exceeded global retry quota)

[Sami, 2015-07-16 12:43:12]

The CQ bit was checked by skyostil@chromium.org

[Sami, 2015-07-16 12:43:12]

The patchset sent to the CQ was uploaded after l-g-t-m from
alexclarke@chromium.org
Link to the patchset: https://codereview.chromium.org/1223163006/#ps100001
(title: "Perf test build fix")

[commit-bot: I haz the power, 2015-07-16 12:43:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1223163006/100001

[commit-bot: I haz the power, 2015-07-16 12:55:32]

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

[commit-bot: I haz the power, 2015-07-16 12:55:33]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

(exceeded global retry quota)

[Sami, 2015-07-16 13:04:12]

The CQ bit was checked by skyostil@chromium.org

[Sami, 2015-07-16 13:04:12]

The patchset sent to the CQ was uploaded after l-g-t-m from
alexclarke@chromium.org
Link to the patchset: https://codereview.chromium.org/1223163006/#ps120001
(title: "Add missing include to IdleHelperTest.")

[commit-bot: I haz the power, 2015-07-16 13:04:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1223163006/120001

[commit-bot: I haz the power, 2015-07-16 14:39:37]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-07-16 14:40:42]

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