Re: [whatwg/dom] Add AbortSignal.any() (PR #1152)

> Yeah though I suspect very long chains with that sort of dependencies aren't common/practical anyway? Any chance you can provide an example? The motivating examples I've used in the past is "signal for server + signal for each request" in Node and "tree of components where cancellation propagates" in web components/browsers.
> 
> In what case is an action hierarchical but the intermediate steps go "out of scopes" before the last steps?

Maybe tree-of-components like thing happening async, e.g. everything is scheduled (child tasks run after/are scheduled from parent tasks)? Abstract, but internally someone brought up something like task A spawns B spawns C etc. where each has a signal argument that gets cloned using the API.

I'm not sure how realistic such situations will be. Intuitively, I thought (think) hierarchical abort made sense: source is aborted completely, then dependents, rather than things being interleaved. In that case, this optimization still affects the order that things fire (hence speccing it), but it holds the invariant that sources are aborted before dependents.

> This change fundamentally uses a way to subscribe to signals that is _different_ from what is accessible to userland and userland can't reproduce in a spec-complaint way on a regular EventTarget. This is unlike promises where the order is coonsistent.

I think you could monkeypatch `AbortSignal.prototype.abort` and `AbortSignal.timeout` to get the proposed ordering? Here's a [proof-of-concept](https://gist.github.com/shaseley/f16655b5a1e2ddcb2341d39d6ea5f2e8) polyfill that provides the spec ordering for the test in question.

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

Message ID: <whatwg/dom/pull/1152/c1535453039@github.com>