proposal-atomics-wait-async
proposal-atomics-wait-async copied to clipboard
tc39
"asynchronous atomic wait" for ECMAScript
Chrome/Edge: [available in Chrome 87+](https://chromestatus.com/feature/6243382101803008) Safari: [landed in Safari TP](https://bugs.webkit.org/show_bug.cgi?id=241414) Firefox: [available under `javascript.options.experimental.atomics_waitAsync` flag](https://bugzilla.mozilla.org/show_bug.cgi?id=1467846) (in Nightly only?)
Ref: https://es.discourse.group/t/atomics-wait-waitasync-as-native-settimeout/1120 It may be worth considering the security implications of this, if you haven't already. (Obviously, SES won't be impacted as it already denies `SharedArrayBuffer`.) Also may be worth...
Using `` (and ``) makes it much easier to tell at a glance which sections are being newly added.
This consolidates two fixes into one PR, but keeps them separate by commit
Reviewers: - [x] @littledan - [ ] @kmiller68 - [x] @rwaldron Editors: - [x] @ljharb - [ ] @syg - [ ] @bakkot - [ ] @michaelficarra
It seems for this to work you effectively need to queue a task (for HTML integration) from which to resolve the promise. As promises cannot be resolved "out of nowhere".
The spec text for [AddAlarm](https://tc39.es/proposal-atomics-wait-async/#sec-addalarm) contains: > After timeout milliseconds has passed, perform the following actions concurrently: The actions here seem to avoid directly running JavaScript, which shouldn't be run...
Just stating I'd love to have this around, I'm looking into message busses for Node and having `.wait` be blocking means scaling up Worker counts to :( levels.
