[Webkit-unassigned] [Bug 271756] New: Can new Worker() be made to properly operate on the background (maybe when the URL is an in-memory Blob)?

Wed Mar 27 04:30:59 PDT 2024

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

            Bug ID: 271756
           Summary: Can new Worker() be made to properly operate on the
                    background (maybe when the URL is an in-memory Blob)?
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jujjyl at gmail.com

Would it be possible to make the following code not deadlock the browser?

`a.html`
```html
<html><body><script>
fetch('a.js').then(response => response.blob()).then(blob => {
  let worker = new Worker(URL.createObjectURL(blob));
  let sab = new Uint8Array(new SharedArrayBuffer(16));
  worker.postMessage(sab);
  console.log('Waiting for Worker to finish');
  while(sab[0] != 1) /*wait to join with the result*/; 
  console.log(`Worker finished. SAB: ${sab[0]}`);
});
</script></body></html>
```
`a.js`
```js
onmessage = (e) => {
  console.log('Received SAB');
  e.data[0] = 1;
}
```
Observed: browser hangs on the `while()` loop.

Expected: `new Worker()` would be great to make progress asynchronously, and the code would print out
```
Worker finished. SAB: 1
```
Some background: This deadlock is causing headaches to users of SharedArrayBuffer/WebAssembly, and leads to poor startup time and over-subscription of web resources on shipped web sites. If it was possible to make the above code work and not deadlock, it would greatly improve startup time and performance of SharedArrayBuffer-utilizing web sites.

Note that we are not asking `new Worker(arbitraryUrl)` to necessarily have this forward-progress guarantee, but that at least that `new Worker(blobUrlInMemory)` would do so (like illustrated in above code). Would that be feasible?

-- 
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/20240327/7301125d/attachment.htm>