Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

> I'm not really sold on the benefits of doing this on the controller when we'll have an observer. I don't think it really matters who aborted the fetch, it's more about the result.

Another reason I'm uneasy about the signal-that-can-potentially-control-multiple-otherwise-independent-fetches model, elaborating a bit on what I alluded to [here](https://github.com/whatwg/fetch/issues/447#issuecomment-292785655): if the network thread is truly *independent* of the scripting thread, there could be hitches on *that* side, meaning that callbacks could fire in JS where *some* of the fetches attached to the signal have been aborted, and others are *still pending evaluation of the signal* - and that doesn't feel like it's going to play well with a lot of the other assumptions that are getting introduced into the mix here (like a promise choosing not to resolve based on a read of the signal?)

[Again](https://github.com/whatwg/fetch/issues/447#issuecomment-281761566), I can't lay down a formal proof of what's wrong with this picture, but something in my gut is telling me it's not adding up, that there's at least one scenario where [the arrows cross into a void](https://github.com/whatwg/fetch/issues/448#issuecomment-275274933).

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