[Webkit-unassigned] [Bug 262948] New: Atomics.wait(sb, 0, 0, 42) stale/breaks on Atomics.notify(sb, 0)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=262948

            Bug ID: 262948
           Summary: Atomics.wait(sb, 0, 0, 42) stale/breaks on
                    Atomics.notify(sb, 0)
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: andrea.giammarchi at gmail.com

Created attachment 468143

  --> https://bugs.webkit.org/attachment.cgi?id=468143&action=review

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231010/3eb3fa7e/attachment-0001.htm>