Bug 262948 – Atomics.wait(sb, 0, 0, 42) stale/breaks on Atomics.notify(sb, 0)

• Status: NEW
• Component: JavaScriptCore

[Andrea Giammarchi]

Created attachment 468143 [details]
index.html + worker.js which stale almost in any condition

There are similar yet slightly different bugs filed for both Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1491342 and Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1858092 but the culprit is the same: looping thousand times Atomics dance breaks, in WebKit TP more than any other browser, in way that makes the browser stale or unresponsive, completely defeating the whole purpose of having Atomics and SharedArrayBuffer dance between workers and the main thread.

Please see the attached file where theoretically one could comment out the while loop and use just `wait(i32a, 0)` on the worker, but that would still stale before finishing the loop here, while it works reliably in Firefox. However, if you don't comment that out, even if you comment out the `i32a[0] = -1` on main, which works in both Firefox and Chromium, WebKit still crashes, becomes unresponsive, or breaks unexpectedly.

I don't even mind having to set some value explicitly, even if it's not clear why just notifying a shared buffer without setting any value would break, but the situation here is pretty unstable compared to others that at least have some workaround.

Thank you in advance for investigating the issue.

[Andrea Giammarchi]

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.

[Andrea Giammarchi]

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`

[Andrea Giammarchi]

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).

[Iain Ireland]

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.

[Andrea Giammarchi]

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.

[Andrea Giammarchi]

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

[Radar WebKit Bug Importer]

<rdar://problem/117066393>