Re: [whatwg/fetch] Editorial: account for removal of AbortSignal's follow (PR #1646)

Thanks for drafting this! I started hacking on this yesterday too, and was leaning towards having "create" take a signal and setting the Request's signal to that, with SW passing a new signal and fetch passing a composite signal.

The reason for doing that vs. always creating a composite signal is because SW invokes "signal abort" directly on the signal, acting as its own (abort) controller. Having a composite signal only be aborted by its sources is a useful property (and IMO expected), e.g. it can be GCed when all its sources are gone; having the signal itself be a source complicates that.

Aside: It might be nice if "signal abort" was private and always done through a controller, separating the control/signal functionality like we do in userland. Specs that need to trigger an abort (SW, streams, maybe navigation API) could hold onto a controller, although it adds a bit of complexity. (Implementation-wise, I've annotated these signals as "internal" and allow/expect them to act like a controller/signal pair).

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

Message ID: <whatwg/fetch/pull/1646/c1532212040@github.com>