- From: Scott Haseley <notifications@github.com>
- Date: Tue, 09 May 2023 21:13:41 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/1152/c1541328010@github.com>
> @shaseley I guess it's worth investigating how complex using abort algorithms would be to not change that test, When creating a dependent signal, we'd need to add an algorithm to each signal provided (and not flatten the dependency graph since that affects order). The algorithms would need to be held weakly, tied to the dependent signal's lifetime in some way. Since IIUC abort algorithms aren't GCed objects, probably the way to do this would be to make "abort algorithms" a weak map using a unique GCed object as the key, either provided or created by "add" (we actually do this in blink to prevent algorithms from leaking). But I think this gets a bit unwieldy because we'd need to either: 1. Always hold algorithms weakly, changing all the specs that use AbortSignal to hold onto the key (or provide one). And also change add, remove, etc. 1. Support both weak and strong algorithms, with dependent signals managing the "any" algorithm key objects and the target signal managing other algorithm keys. This is possible, but seems like an unfortunate bit of complexity. > but if it ends up being unwieldy I think changing the expectation should be safe enough. > Yeah, I think changing the expectation should be reasonably safe, and I think that makes sense to do that. I don't think it's worth the complexity unless we want to always hold algorithms weakly (and update all the specs). -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/pull/1152#issuecomment-1541328010 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/pull/1152/c1541328010@github.com>
Received on Wednesday, 10 May 2023 04:13:47 UTC