Passage of time with SharedArrayBuffer and setTimeout

The web platform has (at least) two places where timeouts are accessible:

• With HTML timers, used by setTimeout.
• With the JS Suspend algorithm, which is called by Atomics.wait.

There is some different text in each to explain how the passage of time affects when the timeout is triggered. In HTML, step 15 of timer initialization steps:

If method context is a Window object, wait until the Document associated with method context has been fully active for a further timeout milliseconds (not necessarily consecutively).

Otherwise, method context is a WorkerGlobalScope object; wait until timeout milliseconds have passed with the worker not suspended (not necessarily consecutively).

In JavaScript, from the Suspend algorithm:

for up to timeout milliseconds

I'm wondering whether we should be applying to Atomics.wait the logic about time not passing while the global scope is suspended. I'm not sure how to test whether this would match current implementations, though (since I'm not sure how to trigger the suspended state programmatically).

One similarity is that both mechanisms have a concept of cancelling these timeouts/alarms. In the Atomics.waitAsync proposal, this cancelling concept is made even more explicit. It feels weird to me for both levels to have their own mechanism for managing these timers; I wonder if JS should defer to HTML here, but that only makes sense if they account for time the same way.

cc @syg @lars-t-hansen @annevk . Previous discussion: https://github.com/tc39/proposal-atomics-wait-async/issues/6#issuecomment-488612551

Start by comparing HTML's timer initialization steps with ECMAScript's Suspend algorithm, then review the linked Atomics.wait and Atomics.waitAsync discussions. No file, test, or implementation entry point is named; done would require a decided specification treatment for elapsed time during suspension and a way to validate it against implementations.