Re: [whatwg/dom] `AbortSignal.timeout()` may not abort past the timeout while performing synchronous work (Issue #1461)

nstepien left a comment (whatwg/dom#1461)

>Are you suggesting that `AbortSignal.timeout()` should update the `aborted` flag from outside the task queue (e.g. in parallel), so that it can be observed even during long-running synchronous execution?

Sort of, I wish `.aborted` was getter that would check if the signal timed out, likewise for `throwIfAborted()`, but it seems beyond the scope/intent of the original `AbortSignal`.
Maybe a new `TimeoutSignal` API with different semantics would be better?
I tried implementing a `class TimeoutSignal extends AbortSignal`, but that's not allowed it seems ("Illegal constructor").

Proxying a signal has its own issues too, it seems:
```js
const signal = AbortSignal.timeout(500);
const proxiedSignal = new Proxy(signal, {});
// AbortSignal.any fails with
// Failed to execute 'any' on 'AbortSignal': Failed to convert value to 'AbortSignal'.
AbortSignal.any([psig]);
```

>You should probably queue tasks to perform your work as to not block the event loop.

That makes sense in general, until you pass your own signal to code you don't have control over, which may have a bug.

Even if you schedule your task carefully, it may be possible to pass a signal to a library which checks for `signal.aborted` without yielding to other tasks.

The opposite is also possible: the library gives you a signal, and you don't yield to the main thread to check if the signal is aborted, for example:
```js
lib.performTask({
  task: fn,
  runCheck({ signal }) {
    // is it obvious that I must yield to the main thread first here?
    return !signal.aborted && condition;
  }
});
```
It's not necessarily about stopping infinite loops, some tasks may take longer than anticipated/desired.

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

Message ID: <whatwg/dom/issues/1461/4111580755@github.com>