In parallel steps that resolve/reject promises without queuing a task #1

tidoust · 2024-06-20T21:20:40Z

Below is a list of specs known to Webref that reference the in parallel term.

Unchecked specs contain at least one algorithm with steps that resolve/reject a promise while running in parallel without queuing a task first, or have some related issue described in a short comment next to the spec name. In other words, they define something like:

X. Run the following steps in parallel:

Resolve/Reject p with foo.

... instead of:

X. Run the following steps in parallel:

Queue a task on [task source] to resolve/reject p with foo.

Checked specs look correct at first glance. Some of them simply reference the term in a note and do not define actual algorithms with steps in parallel.

Other specs that use "in parallel" without linking to its definition in HTML:

Notes:

The full list was computed automatically from Webref data. The review process was manual. I may have missed problems in some of the specs.
Some specs use "in parallel" but do not link back to its definition in HTML. I added some of them manually above. No doubt there are other specs in that category!

Note the logic requires that Webref data contains algorithm extracts. The initial logic reports algorithms that run steps in parallel, and that resolve/reject promises (or fire an event) within these steps without first queuing a task. The analysis logic remains very basic but manages to extract the vast majority of problems that had been manually identified in: tidoust/parallel-promise#1 It also reports a few additional problems that had been missed in HTML, WebXR, Element Capture, Managed Configuration API, Viewport Capture and WebHID. HTML. Cases that are not yet detected include: - indirect problems: when an algorithm step that runs in parallel calls another algorithm that contain steps that cannot run in parallel - use of "parallel queue" instead of "in parallel". Two false positives are currently reported for the Clipboard API and Push API, the former because "resolve" is used to mean something else, the latter because "resolve" is used as a condition ("if all promises resolve").

Note the logic requires that Webref data contains algorithm extracts. The initial logic reports algorithms that run steps in parallel, and that resolve/reject promises (or fire an event) within these steps without first queuing a task. The analysis logic remains very basic but manages to extract the vast majority of problems that had been manually identified in: tidoust/parallel-promise#1 It also reports a few additional problems that had been missed in HTML, WebXR, Element Capture, Managed Configuration API, Viewport Capture and WebHID. HTML. Cases that are not yet detected include: - indirect problems: when an algorithm step that runs in parallel calls another algorithm that contain steps that cannot run in parallel - use of "parallel queue" instead of "in parallel". A few false positives are currently reported for the Clipboard API, Push API and Prevamped Rendering specs, typically because "resolve" is used in contexts with other meanings.

This initial logic reports algorithms that run steps in parallel, and that resolve/reject promises (or fire an event) within these steps without first queuing a task. The analysis logic remains very basic but manages to extract all problems that had been manually identified (with two exceptions detailed below): tidoust/parallel-promise#1 It also reports additional problems that had been missed in HTML, WebXR, Element Capture, Managed Configuration API, Viewport Capture and WebHID. The two exceptions are that are not yet detected automatically are: - indirect problems: when an algorithm step that runs in parallel calls another algorithm that contain steps that cannot run in parallel. This happens in Manifest Incubations: https://wicg.github.io/manifest-incubations/#dfn-steps-to-notify-that-an-install-prompt-is-available - use of "parallel queue" instead of "in parallel", in Web Locks API and Web Periodic Background Synchronization: https://w3c.github.io/web-locks/#ref-for-lock-task-queue https://wicg.github.io/periodic-background-sync/#process-periodic-sync-registrations-algorithm A couple of cases need to be hardcoded to account for uses of "in parallel" and "resolve" to mean something else in the Clipboard APIs, Push API and Prerendering Revamped specs. The whole logic obviously needs algorithm extracts to be present in Webref!

This initial logic reports algorithms that run steps in parallel, and that resolve/reject promises (or fire an event) within these steps without first queuing a task. The analysis logic remains very basic but manages to extract all problems that had been manually identified (with two exceptions detailed below): tidoust/parallel-promise#1 It also reports additional problems that had been missed in HTML, WebXR, Element Capture, Managed Configuration API, Viewport Capture and WebHID. The two exceptions are that are not yet detected automatically are: - indirect problems: when an algorithm step that runs in parallel calls another algorithm that contains steps that cannot run in parallel. This happens in Manifest Incubations: https://wicg.github.io/manifest-incubations/#dfn-steps-to-notify-that-an-install-prompt-is-available - use of "parallel queue" instead of "in parallel", in Web Locks API and Web Periodic Background Synchronization: https://w3c.github.io/web-locks/#ref-for-lock-task-queue https://wicg.github.io/periodic-background-sync/#process-periodic-sync-registrations-algorithm A couple of cases need to be hardcoded to account for uses of "in parallel" and "resolve" to mean something else in the Clipboard APIs, Push API and Prerendering Revamped specs.

This was referenced Jul 8, 2024

Add initial logic to study in parallel algorithm steps w3c/strudy#645

Merged

Automated analysis of in parallel algorithms #2

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

In parallel steps that resolve/reject promises without queuing a task #1

In parallel steps that resolve/reject promises without queuing a task #1

tidoust commented Jun 20, 2024 •

edited

Loading

In parallel steps that resolve/reject promises without queuing a task #1

In parallel steps that resolve/reject promises without queuing a task #1

Comments

tidoust commented Jun 20, 2024 • edited Loading

tidoust commented Jun 20, 2024 •

edited

Loading