Implement Worker.prototype.terminate()

[jwilm]

Adds support for terminating DOM workers. ScriptMsg::Terminate was added to notify the WorkerGlobalScope/DedicatedWorkerGlobalScope to stop processing events and shut down. A closing flag was added to WorkerGlobalScope per the spec.

Additionally, a closing flag was added to dom::worker::Worker to ensure no further events are dispatched to the onmessage handler.

The change to the wpt WorkerTerminate.js is a patch for the broken Worker_terminate_event_queue test (asserts 10001 == 10000).

Resolves #4427

[highfive]

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @jdm (or someone else) soon.

[hoppipolla-critic-bot]

Critic review: https://critic.hoppipolla.co.uk/r/4802

This is an external review system which you may optionally use for the code review of your pull request.

In order to help critic track your changes, please do not make in-place history rewrites (e.g. via git rebase -i or git commit --amend) when updating this pull request.

[jwilm]

The spec specifies to empty the event/task queue associated with the worker as to not deliver further events to the onmessage handler. Without a synchronous way to affect the DedicatedWorkerGlobalScope, I resorted to these short-circuiting checks to prevent messages from being delivered. I keep thinking about this because it's kind of ugly. Does someone have any perspective on a cleaner way to achieve that behavior?

[jwilm]

Gecko appears to differentiate between normal events in the worker thread's queue and what it calls a ControlRunnable. The run loop in their worker prioritizes the control events and handles at most one normal event on an iteration. We could implement something similar by adding a control channel and moving to a select model for the loop.

[Ms2ger]

I commented on critic.

[jwilm]

I left a couple of comments/questions in reply.

Do reviewers get notified of replies from critic, or should I ping from the issue?

[jdm]

The comments arrive in email form; no ping necessary.

[jwilm]

I fixed all of the issues on critic except escaping a long running JS handler. Interrupting JS execution in this case requires a call to JS_RequestInterrupt from Worker. This means that both Worker and DedicatedWorkerGlobalScope need a reference to the Runtime. However, we cannot Send Runtime or Cx in the current rust-mozjs, and so there's no way to schedule an interrupt. A higher level API in rust-mozjs that handles safe concurrent access to the runtime would make this possible.

[jwilm]

The latest changes add support for killing a blocking script in the worker. Such capability requires a reference to the JSRuntime in Worker. I think this highlights the need for building out a sendable runtime in mozjs-rust. There's a couple of unsafe sections in both DedicatedWorkerGlobalScope and Worker to handle managing the mozjs interrupts. Again, we need more safe APIs from mozjs-rust.

It might be good to have a second channel for workers as well. I ended up needing to buffer ScriptMsgs outside of the receiver. This wouldn't even be a problem if there was a dedicated channel for control messages.

The code in tests/html/worker was for validation that the thread count was not increasing after spawning/terminating numerous workers. It would be nice to automate that, but for now there's test pages.

[Ms2ger]

Please rebase on master.

[Ms2ger]

Rebased as #6652