What goes into "in parallel" blocks vs. in a task?

[TimothyGu]

After some confusion on IRC, some explicit guidance for what are allowed in "in parallel" blocks versus what should go into "queue a task" seems essential. Should these be allowed?

1. Modifying JavaScript-visible state, like firing an event. This is already a pretty big no-no for self-evident reasons, but we should definitely make them clear through examples. This should include resolving and rejecting promises, the order of which is JavaScript-observable through ordering.

2. Creating new IDL platform objects. This has already been covered in State that by default all objects are created in the relevant realm of this webidl#135, and even though a brief search hasn't turned up any usage, I wouldn't be surprised if there are specs out there doing this in parallel. Even though creating bare-bones objects should not be observable to user JavaScript, it seems wrong to manipulate the JavaScript execution state in any way from a different thread. Additionally, due to the similarity to the first bullet point, it's probably easier to forbid this moving forward.

3. Creating non-object IDL or Infra values, like lists, strings, USVString, dictionary, etc. These should be OK. However, creating FrozenArray should fall into 2 and thus not okay.

What makes it worse is the fact that the "good" example in https://html.spec.whatwg.org/multipage/infrastructure.html#parallelism has this in parallel:

If nameList contains name, reject p with a TypeError and abort these steps.

which seems doubly/triply bad:

• It rejects a promise, which is a JavaScript-visible action, i.e., item 1 above.
• It creates a new TypeError object, i.e., item 2 above.
• IIRC we've been trying to move away from "abort these steps", but neither "return" nor "break" seems appropriate here.

[domenic]

https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors covers this in all the detail you're asking, I think.

"resolve/reject" implicitly queue a task right now, per the definitions in https://www.w3.org/2001/tag/doc/promises-guide#shorthand-manipulating. Those aren't perfect in various ways (e.g. they don't state a task source). But that's the story.

[jakearchibald]

2 was my main confusion.

Along with: If I return the same IDL instance twice, what guarantees JavaScript will get the same object twice? But I guess that's a question for WebIDL.