Make task queue selection per agent rather than per scheduler

[shaseley]

The postTask spec allows the next Scheduler task to be the oldest, highest priority task from any of its task queues, enabling per-frame task prioritization decisions. But HTML task queues are per agent/event loop, and as such other scheduling decisions typically cannot take into account a task's frame. It's not clear there's a benefit to enabling some tasks to be per frame while others are per agent, and removing this simplifies things and makes overall prioritization easier to understand, which is what this change does.

---

Preview | Diff

[shaseley]

Friendly ping @clelland @mmocny. Not sure if adding as reviewers sent emails or not.

[mmocny]

LGTM.

I do have a question which I will follow-up with: If each task has a "next enqueue order" and a priority, what happens when you adjust a task priority with a TaskSignal? Would it be re-assigned a new enqueue order (i.e. go to the back of the new priority-level task queue), or would it be "merged into" according to its previous enqueue order?

This might be specified!

[mmocny]

Given the note about timestamps as an alternative (below), would this value be entirely optional?

Similarly, in the scheduler task definition, there is an "enqueue order" which is specifically initialized to 0, and then algorithms specifying how to assign and increment -- all these need to be timestamps in that case I think.

While this alternative is likely easily implied by the note below, just checking if you should make explicit reference to all the changes that would be made with that alternative or not.

I wonder if that would be easier if you just have an algorithm for "get next enqueue order value" or something like that. It could be implemented to increase a counter, or to return a unique+increasing timestamp.

Then, perhaps the rest of the references would not care if its a timestamp or number.

[shaseley]

Ah, yeah it's optional if you choose to use timestamps. I chose to use an enqueue order since it's easy to understand and matches Chrome's implementation. I also removed the note about using a timestamp since I'm not sure how much that adds -- it's clear in the spec where the value is set, and implementations in general can make different choices as long as the observable behavior is the same.