Enhance the worker script loader to use PFetch for its fetches so Worker creation and worker script loading do not block while waiting on the main thread (which currently performs the network fetches on behalf of the worker)
Categories
(Core :: DOM: Workers, enhancement)
Tracking
()
People
(Reporter: asuth, Unassigned)
References
(Blocks 2 open bugs)
Details
Currently because of limitations on worker script loading, a Worker that is started from JS code cannot possibly start loading until control flow is yielded. Once bug 1351231 is landed, we can build on Yulia's worker script loader cleanups to move the network and Cache related steps to the worker thread from the main thread.
This limitation currently means that the fuzzer can create a number of OOM bugs like bug 1797413 that other engines may not experience. We should expect a large number of bugs to end up depending on this bug, although possibly through an intermediary meta bug.
|
Reporter | |
Updated•1 year ago
|
|
||
Comment 1•4 months ago
|
||
Is this actionable now 1351231 is fixed, and do we still stand to gain from doing this? Should it be prioritized? It also sounds interesting from a performance perspective...
|
|
Reporter | |
Comment 2•4 months ago
|
||
This is still worth doing and there are expected performance benefits for contended main threads. This is part of our expected worker refactoring path to enable ServiceWorkers to not involve the main thread, although we have a mitigation in place for ServiceWorkers where they are spawned in their own process remoteType so the main thread is expected to not be contended.
|
|
Reporter | |
Comment 3•9 days ago
|
||
Duping forward to bug 1899507 that Eden filed since my comment there is more useful and up-to-date than my comments here and he's assigned to that bug.
Description
•