Description
https://drafts.css-houdini.org/worklets/#dom-worklet-addmodule
Right now, step 12 queues a task on each global, calling https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script.
Step 2 waits on the completion of "fetch a worklet script".
This either "waits" on the event loop, or does some sort of requeueing as hinted by "asynchronously completes".
Neither is great. Consider:
CSS.paintWorklet.addModule('circle.js');
// Then later:
CSS.paintWorklet.addModule('square.js');If the event loop is blocked, the fetch of square.js will block any of circle.js's operations. Blocking painting on a fetch seems bad.
If some requeueing is happening, there's a race where square.js will have loaded in some threads, but not others. This means CSS will get an image, or an invalid image, depending on which global it calls, potentially resulting in flickering.
It feels like the fetch of the module should happen before any tasks are queued, then queue tasks to execute the module in the various globals. However, this needs to be atomic, in that no further tasks are executed until all globals have executed their tasks.
https://html.spec.whatwg.org/multipage/infrastructure.html#parallelism might help here, but we may need to enhance it with some kind of "shared" vs "exclusive" model similar to https://github.com/inexorabletash/web-locks.