Re: [whatwg/dom] Request for a different type of example of abort steps (Issue #1031)

Looks pretty good to me! Only one issue, not related to the aborting stuff: don't forget to queue a task for "resolve" too; and, try these days to use "queue a global task" instead of "queue a task" for precision.

I think the alternative to the flag approach would be when the in-parallel action is vague enough that specs sum it up in a single step, and so you can say something similarly-vague like "interrupt the process". E.g. something like

1. Let global be this's relevant global object.

1. Let p be a new promise.

1. If options["signal"] member is present, then:

    1. Let signal be options["signal"].
    
    3. If signal is aborted, then reject p 
       with signal’s abort reason and return p.

    4. Add the following abort steps to signal:

        1. Abort the process of reading from the I/O device.

1. In parallel, read from the IO device. When this completes (in any fashion), queue a global task on the X task source given global to perform the following steps:

    1. If reading completed successfully, resolve p with the result of creating an ArrayBuffer from the bytes read.

    1. If reading failed due to I/O issues, reject p with a "OperationError" DOMException.

    1. If reading was aborted, reject p with signal's abort reason.

4. Return p.

If your in-parallel action has multiple interesting steps, with well-defined points at which you would check the aborted flag, then being precise about that like you outlined is better.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1031#issuecomment-966516722