| Summary: | Atomics.wait(sb, 0, 0, 42) stale/breaks on Atomics.notify(sb, 0) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Andrea Giammarchi <andrea.giammarchi> | ||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | iireland, keith_miller, mark.lam, webkit-bug-importer, ysuzuki | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari Technology Preview | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Andrea Giammarchi
2023-10-10 03:34:15 PDT
To whom it might concern, Firefox gave me a very (ugly yet) detailed answer around *their* behavior: https://bugs.chromium.org/p/chromium/issues/detail?id=1491342 Feel free to follow up on my reply but the elephant in the room here is that WebKit doesn't really follow their reasoning and it just breaks unpredictably expectations. FWIWI I would be OK with Firefox resolution, as it means the specs are ugly and likely have bugs or not friendly at all outcome for JS developers, but at least following Firefox approach would be consistent. 2 other issues in 2 different spaces had problems in running the demo so just in case you have too, you need to enable SharedArrayBuffer at both browser and headers (server) level. I use `npx static-handler --coi .` where `.` is the current folder and that should be enough to have SharedArrayBuffer available. I also use an explicit flag in Epiphany TP such as `export JSC_useSharedArrayBuffer=1` The underlying issue has been addressed and solved in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1858092#c7 and basically it's rather lack of better documentation around the third argument of Atomics.wait. This is still a completely unexpected behavior from WebKit as it doesn't apparently follow standards and it stale unpredictably, so it's up to you to either investigate and fix this issue or close it as the workaround seems to work reliably enough (Epiphany TP crashes every single time but that's maybe another story ... although the loop ends every time). To save whoever ends up investigating this some time: WebKit's behaviour here is correct and standards-compliant. The reporter had two problems: 1. If you call Atomics.wait in a loop with a timeout, and only call Atomics.notify once, then the notify might fire after one wait has timed out, but before the next wait has begun, in which case the notify will return 0 and you will end up looping forever. 2. If you call Atomics.wait with a `value` argument that does not match the current value, then you will not wait at all. This can make it harder to understand problem 1. No changes in WebKit are necessary. the point 1 above is not what happens and results are different from what happens in Firefox. In firefox notifying with value `0` never produces an 'ok' here sometimes it does, sometimes it doesn't, as explained in my last comment. to whom it might concern, there's a video about this bug and it's similar in WebKit too, and it has nothing to do with whatever the FF developer mentioned: https://www.youtube.com/watch?v=Wx5BKw9ol7E |