- From: Scott Haseley <notifications@github.com>
- Date: Tue, 02 May 2023 16:20:27 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/1152/review/1410002816@github.com>
@shaseley commented on this pull request. > - <li><p>If <var>parentSignal</var> is [=AbortSignal/aborted=], then - <a for=AbortSignal>signal abort</a> on <var>followingSignal</var> with <var>parentSignal</var>'s - [=AbortSignal/abort reason=]. + <li><p>Set <var>resultSignal</var>'s [=AbortSignal/composite=] to true. I think setting it after checking aborted signals is probably okay, or at least functionally equivalent? If it's an empty list, I think it should still be composite. If not, the signal could be added as a source for another composite signal, e.g. ```js let signal1 = AbortSignal.any([]); // If `signal1` is not composite, it would be added as a source for `signal2`, but // it will never be aborted. let signal2 = AbortSignal.any([signal1, realSignal]); ``` That would affect GC eligibility: `signal1` should be GC-able immediately and `signal2` would be GC-able when `realSignal` is GCed. I think this maybe comes down to how SW/internal signals are handled. In https://github.com/whatwg/fetch/pull/1646#issuecomment-1532212040, I'm advocating for SW not creating a composite signal (or at least creating one with a source signal it controls) to avoid composite signals being aborted directly, which I think would be surprising (a hidden source!). -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/pull/1152#discussion_r1183129299 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/pull/1152/review/1410002816@github.com>
Received on Tuesday, 2 May 2023 23:20:32 UTC