[worklets] Make "Code Idempotency" section normative and stronger

[SimonSapin]

https://drafts.css-houdini.org/worklets/#code-idempotency is a non-normative section that starts with:

Multiple instances of WorkletGlobalScope can be created for each Worklet that they belong to. User agents may choose to do this in order to parallelize work over multiple threads, or to move work between threads as required.

In order to help make that possible, it goes on with content such as:

authors […] should make their code idempotent.

User agents may choose to always have at least two WorkletGlobalScopes per Worklet

I think this is not enough. If one major implementation ships for example CSS Layout API without these "may" precautions, it is likely that many websites will rely and worklet methods being executing in a certain order and in the same global scope. This might effectively make parallelization web-incompatible.

I’d like to make this section normative, and have it specify "must" requirements for user-agents. The details can be discussed, but one idea is to use JavaScript Frozen Realms to make the global scope immutable (or have an immutable prototype so that creating a new global scope with that same prototype is cheap and could be done for every call).

CC @tschneidereit

[RByers]

Note that some uses cases (eg. animationworklet) absolutely need some way to pass state from one invocation to the next in a serial fashion. But this can be explicit according to some contract, not depending on the global object.

[SimonSapin]

From today’s meeting:

RESOLVED: Paint/Layout specs will have normative section that implementations must have at least 2 globals with an opt-out for memory constraints.

@RByers when such state needs to be passed around, I think it should be explicit though parameters and return values rather than implicit side effects.

[RByers]

@RByers when such state needs to be passed around, I think it should be explicit though parameters and return values rather than implicit side effects.

Absolutely. See the above issue for one example of how we're doing this in a demo.

[esprehn]

re FrozenRealms they require freezing all of the globals and all of prototypes of everything which means you can't use polyfills or work around API bugs easily. They also have some serious restrictions:
https://github.com/FUDCo/proposal-frozen-realms#date-and-math It's also not clear how they interact with ES modules, for example I think modules can do "default export []" and export a mutable array, and modules are de-duplicated, so now you have global state to deal with.