[css-houdini-drafts] [worklets] addModule is either blocking or racey

jakearchibald has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [worklets] addModule is either blocking or racey ==
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:

```js
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.

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/474 using your GitHub account

Received on Thursday, 12 October 2017 09:19:47 UTC