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

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from jujjyl at gmail.com ---
> I don't think that we'd be encouraging blocking main thread while waiting for background thread operation, the whole point of workers is that they work without blocking the main thread.

This is a fine sentiment, although it is good to recognize that there are several real-world use cases, where blocking the main thread on worker threads is not just the correct thing to do, but also the only possible thing to do.

One example of this is the multithreaded WebGL/WebGPU scene traversal and update. A typical interactive real-time rendering application will be processing through frames in its requestAnimationFrame() callback. To improve performance of such operation, a common technique is to hand off the scene traversal and update to a number of background Workers, and then wait until these Workers finish, to render the scene contents.

There is no way to achieve the same otherwise, than to make the main thread synchronously block on the Worker threads. This is a hardened battle-tested algorithm in hundreds of native game and 3D applications.

As a second example where synchronously blocking the main thread is the right and most performant thing to do can be found in multithreaded Mark-and-Sweep garbage collection. In https://github.com/juj/emgc you can find an example of a multithreaded GC, to be used for example in compiling a C#, Java or Python VM into WebAssembly.

In such scenario, when the heap runs out of memory on a malloc, the system may need to trigger an on-demand GC to reclaim memory. To improve overall performance of the GC, instead of doing the GC marking phase just on the main thread, it is desirable to do the GC marking phase with the help of multiple Workers. But the inability to launch such GC Workers on demand means that the GC Workers must have been preallocated already at site startup, which is pessimistic for several reasons:
1) the site startup time will be slowed down,
2) the site may not 100% in all cases even need to GC (yet, the GC Workers need to be there and consume memory)
3) the site won't have a way to let go of the GC workers and free up page memory (the GC workers may need to be reused suddenly in the future depending on user access patterns)
4) when composing software from multiple libraries, each library will independently need to pre-create their Workers for their purpose, since coordinating needed Worker counts across unrelated libraries is impossible (would essentially require developer knowing ahead of time how many pthread_create()s their application would ever do in worst case)

If there was a way to launch Workers synchronously from an in-memory Blob URL, then all of the above inefficiencies would be gone: multithreaded sites could launch faster, they wouldn't have to pool up Workers in advance, and performance of abovementioned use cases would be improved.

I can appreciate the concern that it might be complex to implement, though the rationale of "sync blocking is bad" is not at all accurate - in many scenarios sync blocking the main thread can improve both the throughput and responsiveness of a site.

-- 
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/20240328/160cfb11/attachment.htm>