Re: [whatwg/dom] Introduce AbortSignal.timeout() (PR #1032)

I was going to write a big comment with the pros/cons of suspending while in bfcache/in a worker. But in the end it mostly ended up with pros for suspended. So I am currently advocating we keep the `setTimeout()` behavior here, i.e. if you do `AbortSignal.timeout(10_000)`, you need to spend 10 seconds _active_ before the signal aborts, not 10 seconds _wall time_.

Here's was my thought process on the pros/cons of suspending:

- (+) Matches setTimeout() so might be more expected for developers
- (+) Easier to spec and probably easier to implement
- (+/-) Avoids "timer storms" upon reactivation
- (-? but not really) Seemingly doesn't match the primary use case that well, of erroring an operation if it took too long. E.g. if you use `fetch(..., { signal: AbortSignal.timeout(30_000) })`, and the server still hasn't responded after 30 seconds, you don't care whether some of those 30 seconds were spent in bfcache: the server is probably not going to respond.
  - This is why the "timer storms" argument is both a pro and a con: having a bunch of stuff get aborted upon bfcache restore, because it took too long, actually seems OK! It's very different than _running a bunch of code_ upon bfcache restore, which is what you would expect with `setTimeout()`.
  - On the other hand, I believe this scenario isn't realistic: if you go into bfcache, I'm pretty sure all ongoing fetches will be aborted immediately anyway. (Or maybe we just won't let you go into bfcache with ongoing fetches; not sure.)
  - Finally, what really swung this for me was remembering that we use `fetch()`'s `signal` for more than just the network operation: we use it for, e.g., JSON decoding or other consume-body operations. So consider the scenario where the server responds, and perhaps even all of the body is read into memory. But then we go into bfcache, before the promise returned from `json()` can fulfill. If we spend a minute in bfcache and then go back, we don't really want the promise to reject; we want it to do that last tiny bit of work, and fulfill! I think this is probably a specific case of a more general scenario, possibly involving non-browser APIs that use `AbortSignal` and care about timeouts.

@shaseley, does this reasoning seem reasonable to you? I'd like to have your blessing on our decision here, as the person who has thought most about these sorts of timing and scheduling things in Chromium :)

-- 
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/pull/1032#issuecomment-976900712