Bugzilla

So a big divergence between the specs when it comes to workers and the reality of our implementation that ends up interacting with everything here is that terminating a worker is supposed to :
- Step 2 of [terminate a worker](https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker) is "If there are any tasks queued in the WorkerGlobalScope object's relevant agent's event loop's task queues, discard them without processing them."
- And step 1 was setting the [closing flag](https://html.spec.whatwg.org/multipage/workers.html#dom-workerglobalscope-closing) to true which means "the event loop's task queues must discard any further tasks that would be added to them".
- Step 3 is "[Abort the script](https://html.spec.whatwg.org/multipage/webappapis.html#abort-a-running-script) currently running in the worker."

So termination is supposed to conceptually stop the current task in its tracks and prevent any other tasks from ever running again.  To deal with the reality of multi-threaded code, the worker will continue to potentially run runnables for quite some time, specifically as long as StrongWorkerRefs are held.  There had been a broken attempt to require all runnables dispatched to workers to be [nsICancelable](https://searchfox.org/firefox-main/rev/d5171e9e0f4729494423b0524f289073e0f0cb6c/netwerk/base/nsICancelable.idl) (later [nsIDiscardableRunnable](https://searchfox.org/firefox-main/rev/d5171e9e0f4729494423b0524f289073e0f0cb6c/xpcom/threads/nsIDiscardableRunnable.h)), but it wasn't foolproof and most code extended to support workers did not handle the situation correctly or even well.

So we need the dying mechanism as a backstop / defense-in-depth to enforce this state of "the spec says no tasks should ever run beyond this point".  While I know we are talking about microtasks here, there is a meta concern that a spec implementation that looks something like "queue a task to run on global (that is a worker) and then in that task queue a microtask or resolve a promise" and we have been depending on the dying check to let naive code get away with being naive and not necessarily having to call [mozilla::GlobalTeardownObserver::CheckCurrentGlobalCorrectness](https://searchfox.org/firefox-main/rev/d5171e9e0f4729494423b0524f289073e0f0cb6c/dom/base/GlobalTeardownObserver.h#37-47) (where the comment should be updated).

I am happy to go into more of the structural issues and how we might address them, but perhaps one thing we could do is to try and rename "dying" to more directly correlate to a terminated worker.  Unfortunately, [DedicatedWorkerGlobalScope.close](https://html.spec.whatwg.org/multipage/workers.html#dom-dedicatedworkerglobalscope-close) which invokes [close a worker](https://html.spec.whatwg.org/multipage/workers.html#close-a-worker) is notably distinct from [terminate a worker](https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker) in that it continues to let the existing JS on the stack run and I believe is allowed to process microtasks, so "closing" is not an apt description of what's going on (and also would not convey the urgency inherent in termination).  We could certainly rename IsDying to IsTerminating and given how the flag is specialized to workers, we could make it IsTerminatingWorker.

So a big divergence between the specs when it comes to workers and the reality of our implementation that ends up interacting with everything here is that terminating a worker is supposed to :
- Step 2 of [terminate a worker](https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker) is "If there are any tasks queued in the WorkerGlobalScope object's relevant agent's event loop's task queues, discard them without processing them."
- And step 1 was setting the [closing flag](https://html.spec.whatwg.org/multipage/workers.html#dom-workerglobalscope-closing) to true which means "the event loop's task queues must discard any further tasks that would be added to them".
- Step 3 is "[Abort the script](https://html.spec.whatwg.org/multipage/webappapis.html#abort-a-running-script) currently running in the worker."

So termination is supposed to conceptually stop the current task in its tracks and prevent any other tasks from ever running again.  To deal with the reality of multi-threaded code, the worker will continue to potentially run runnables for quite some time, specifically as long as StrongWorkerRefs are held.  There had been a broken attempt to require all runnables dispatched to workers to be [nsICancelable](https://searchfox.org/firefox-main/rev/d5171e9e0f4729494423b0524f289073e0f0cb6c/netwerk/base/nsICancelable.idl) (later [nsIDiscardableRunnable](https://searchfox.org/firefox-main/rev/d5171e9e0f4729494423b0524f289073e0f0cb6c/xpcom/threads/nsIDiscardableRunnable.h)), but it wasn't foolproof and most code extended to support workers did not handle the situation correctly or even well.

So we need the dying mechanism as a backstop / defense-in-depth to enforce this state of "the spec says no tasks should ever run beyond this point".  While I know we are talking about microtasks here, there is a meta concern that a spec implementation that looks something like "queue a task to run on global (that is a worker) and then in that task queue a microtask or resolve a promise" and we have been depending on the dying check to let naive code get away with being naive and not necessarily having to call [mozilla::GlobalTeardownObserver::CheckCurrentGlobalCorrectness](https://searchfox.org/firefox-main/rev/d5171e9e0f4729494423b0524f289073e0f0cb6c/dom/base/GlobalTeardownObserver.h#37-47) (where the comment should be updated) from a runnable that corresponds to a spec task or otherwise potentially induce the running of script.

I am happy to go into more of the structural issues and how we might address them, but perhaps one thing we could do is to try and rename "dying" to more directly correlate to a terminated worker.  Unfortunately, [DedicatedWorkerGlobalScope.close](https://html.spec.whatwg.org/multipage/workers.html#dom-dedicatedworkerglobalscope-close) which invokes [close a worker](https://html.spec.whatwg.org/multipage/workers.html#close-a-worker) is notably distinct from [terminate a worker](https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker) in that it continues to let the existing JS on the stack run and I believe is allowed to process microtasks, so "closing" is not an apt description of what's going on (and also would not convey the urgency inherent in termination).  We could certainly rename IsDying to IsTerminating and given how the flag is specialized to workers, we could make it IsTerminatingWorker.