Run all JS from a task scheduled on the task-queue?

[gterzian]

We currently have a task-queue:

servo/components/script/task_queue.rs

Line 38 in f3b1f0d

pub struct TaskQueue<T> {

To which tasks from all task-sources are scheduled through.

servo/components/script/task_source/mod.rs

Line 45 in f3b1f0d

pub trait TaskSource {

However, not all JS runs via a task-source, for example timers are run directly when receiving a message from the scheduler at

servo/components/script/script_thread.rs

Line 1979 in f3b1f0d

fn handle_timer_event(&self, timer_event: TimerEvent) {

UI events from the compositor are also dispatched directly via

servo/components/script/script_thread.rs

Line 3411 in f3b1f0d

fn handle_event(&self, pipeline_id: PipelineId, event: CompositorEvent) {

So while this is OK, one could argue that these represent distinct task-queues and that only the relative ordering inside a task-queue matters, it can be somewhat surprising. See for example #24664 (comment)

Should we make some effort to route everything through the task-queue? It could then also be a central point where prioritization could be taken into account, in fact it already is, as the task-queue potentially throttles certain task-sources, see

servo/components/script/task_queue.rs

Line 128 in f3b1f0d

TaskSourceName::PerformanceTimeline => return true,

Also, the task-queue has some logic dealing with inactive pipelines, whereas currently timers and compositor events each need to perform their own checks, see for example:

servo/components/script/script_thread.rs

Line 3423 in f3b1f0d

if window.Closed() {

and

servo/components/script/script_thread.rs

Line 1990 in f3b1f0d

if w.Closed() {

[gterzian]

On the downside, it does mean handling a message from the compositor, and then queuing a task(which is essentially sending another message to the script-thread itself). So perhaps the overhead is not worth it for UI events?

Actually, since those message come-in over IPC anyway, we could instead of routing them to a single port using

servo/components/script/script_thread.rs

Line 1263 in f3b1f0d

let control_port = ROUTER.route_ipc_receiver_to_new_crossbeam_receiver(state.control_port);

we could have a more specific routing, for example by plugging certain messages into the task-queue, for example the ConstellationControlMsg::SendEvent could be routed directly into the task-queue, as opposed to into the main select of the script-thread at

servo/components/script/script_thread.rs

Line 1424 in f3b1f0d

recv(self.control_port) -> msg => FromConstellation(msg.unwrap()),

[gterzian]

I've done some reading:

1. It seems UI events don't always have to be disptached inside a task, in fact, it seems they usually aren't dispatched in one at all. See https://w3c.github.io/uievents/
2. Timers should be dispatched from inside a task, using the timer-task-source, so that something we could implement.

[gterzian]

The actionable element is found at #24747