- From: James M Snell <notifications@github.com>
- Date: Sat, 02 Mar 2024 15:04:53 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/1263@github.com>
### What is the issue with the DOM Standard? The `AbortSignal.timeout(...)` method provided us with a nice functional mechanism to abort an operation after a given period of time and was quite a welcome addition. However, there is one use case that it currently does not quite adequately cover: idle timeouts. That is, given a long running operation, the ability to timeout only if there is not regular activity within a given period of time. If there is activity, the timeout resets. For example, let's imagine that we have an async iterable like a `ReadableStream`. Once we start consuming the stream, we want to make sure that each read happens within about one second and that the stream is canceled if the reads do not occur fast enough. This would be difficult with `AbortSignal.timeout(...)` currently without being forced to create a new `AbortSignal` on every iteration, which seems wasteful. Instead, it would be nice to have a single `AbortSignal` timeout that can be reset. ``` const signal = AbortSignal.timeout(1000); // do some work... signal.update(); // reset the timer... // do more work... signal.update(); // reset the timer... ``` Obviously, however, this becomes a bit weird to have an `update()` method on `AbortSignal` instances created in other ways that does not do anything, so I'm not that worried about exactly what the api looks like... I'd mostly like to explore if this use case (specifically, allowing a single timeout-based `AbortSignal` to have it's timer reset) would be interesting. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/1263 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/issues/1263@github.com>
Received on Saturday, 2 March 2024 23:04:57 UTC