Separate out Atomics.waitAsync polyfill. NFC

[sbc100]

Split out from #20404.

Rather than adding artificial dependencies on
emscripten_atomic_wait_async we can use the same technique used by $polyfillSetImmediate in library_eventloop.js.

[tlively]

What are we using this polyfill for?

[sbc100]

What are we using this polyfill for?

See the comments:

// Chrome 87 (and hence Edge 87) shipped Atomics.waitAsync (https://www.chromestatus.com/feature/6243382101803008)
// However its implementation is faulty: https://bugs.chromium.org/p/chromium/issues/detail?id=1167541
// Firefox Nightly 86.0a1 (2021-01-15) does not yet have it, https://bugzilla.mozilla.org/show_bug.cgi?id=1467846
// And at the time of writing, no other browser has it either.
#if MIN_EDGE_VERSION < 91 || MIN_CHROME_VERSION < 91 || MIN_SAFARI_VERSION != TARGET_NOT_SUPPORTED || MIN_FIREFOX_VERSION != TARGET_NOT_SUPPORTED || ENVIRONMENT_MAY_BE_NODE
  // Partially polyfill Atomics.waitAsync() if not available in the browser.
  // Also polyfill for old Chrome-based browsers, where Atomics.waitAsync is
  // broken until Chrome 91, see
  // https://bugs.chromium.org/p/chromium/issues/detail?id=1167541
  // https://github.com/tc39/proposal-atomics-wait-async/blob/master/PROPOSAL.md
  // This polyfill performs polling with setTimeout() to observe a change in the
  // target memory location.

[sbc100]

What are we using this polyfill for?

In order to make the APIs work on browsers that don't support it I assume?

[tlively]

When I wrote the proxying code to use Atomics.waitAsync when available, I deliberately did not include a polyfill because falling back to postMessage should be much, much faster than any possible polyfill. Is there a chance that this polyfill is being picked up and accidentally used by the proxying code?

[sbc100]

When I wrote the proxying code to use Atomics.waitAsync when available, I deliberately did not include a polyfill because falling back to postMessage should be much, much faster than any possible polyfill. Is there a chance that this polyfill is being picked up and accidentally used by the proxying code?

Hmm.. that is possible. Perhaps we should not actually polyfill via the original name.