Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify event loop integration and prioritization #92

Merged
merged 3 commits into from
Jun 5, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions spec/patches.md
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,26 @@ Modify step 2.1 to read:
[=implementation-defined=] manner.
* |schedulerQueue|'s [=scheduler task queue/tasks=], if |schedulerQueue| is not null.

Note: the HTML specification enables per-[=task source=] prioritization by making the selection of
the next [=task=]'s [=task queue=] in the event loop processing steps [=implementation-defined=].
Similarly, this specification makes selecting between the next {{Scheduler}} task and the next task
from an [=event loop=]'s [=task queues=] [=implementation-defined=], which provides UAs with the
most scheduling flexibility.
<br/><br/>
But the intent of this specification is that the {{TaskPriority}} of {{Scheduler}} tasks would
influence the event loop priority. Specifically, "{{TaskPriority/background}}" tasks and
shaseley marked this conversation as resolved.
Show resolved Hide resolved
continuations are typically considered less important than most other event loop tasks, and
"{{TaskPriority/user-blocking}}" tasks and continuations, as well as "{{TaskPriority/user-visible}}"
continuations (but not tasks), are typically considered to be more important.
<br/><br/>
One strategy is to run {{Scheduler}} tasks with an [=scheduler task queue/effective priority=] of 3
or higher with an elevated priority, e.g. lower than input, rendering, and other <em>urgent</em>
work, but higher than most other [=task sources=]. {{Scheduler}} tasks with an [=scheduler task
queue/effective priority=] of 0 or 1 could be run only when no other tasks in an [=event loop=]'s
[=task queues=] are [=task/runnable=], and {{Scheduler}} tasks with an [=scheduler task
queue/effective priority=] of 2 could be scheduled like other scheduling-related [=task sources=],
e.g. the [=timer task source=].

Issue: The |taskQueue| in this step will either be a [=set=] of [=tasks=] or a [=set=] of
[=scheduler tasks=]. The steps that follow only [=set/remove=] an [=set/item=], so they are
*roughly* compatible. Ideally, there would be a common task queue interface that supports a `pop()`
Expand Down
32 changes: 21 additions & 11 deletions spec/scheduling-tasks.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,17 +12,27 @@ This spec formalizes three priorities to support scheduling tasks:
};
</pre>

<dfn enum-value for=TaskPriority>user-blocking</dfn> is the highest priority, and is meant to be
used for tasks that are blocking the user's ability to interact with the page, such as rendering the
core experience or responding to user input.

<dfn enum-value for=TaskPriority>user-visible</dfn> is the second highest priority, and is meant to
be used for tasks that are observable to the user but not necessarily blocking user actions, such as
updating secondary parts of the page. This is the default priority.

<dfn enum-value for=TaskPriority>background</dfn> is the lowest priority, and is meant to be used
for tasks that are not time-critical, such as background log processing or initializing certain
third party libraries.
<dfn enum-value for=TaskPriority>user-blocking</dfn> is the highest priority, and it is meant for
tasks that should run as soon as possible, such that running them at a lower priority would degrade
user experience. This could be (chunked) work that is directly in response to user input, or
shaseley marked this conversation as resolved.
Show resolved Hide resolved
updating the in-viewport UI state, for example.
<br/><br/>
Note that tasks scheduled with this priority will typically have a higher event loop priority
compared to other tasks, but they are not necessarily render-blocking. Work that needs to happen
immediately without interruption should typically be done synchronously &mdash; but this can lead to
poor responsiveness if the work takes too long. "{{TaskPriority/user-blocking}}" tasks, on the other
hand, can be used to break up work and remain remain responsive to input and rendering, while
increasing the liklihood that the work finishes as soon as possible.

<dfn enum-value for=TaskPriority>user-visible</dfn> is the second highest priority, and it is meant
for tasks that will have useful side effects that are observable to the user, but either which are
not immediately observable or which are not essential to user experience. Tasks with this prioriy
are less important or less urgent than "{{TaskPriority/user-blocking}}" tasks. This is the default
priority.

<dfn enum-value for=TaskPriority>background</dfn> is the lowest priority, and it is meant to be used
for tasks that are not time-critical, such as background log or metrics processing or initializing
certain third party libraries.

Continuation priorities mirror task priorities, with an additional option to inherit the current
priority:
Expand Down