Re: [fetch] Aborting a fetch (#27)

> I see nothing automatic about requiring every single reference-holder to signal disinterest before an action is cancelled

The automatic part is that the library keeps track of the references for you and disinterest semantics are preserved.

> I would ask what use-cases merit distribution of control in this manner.

Uh... you're in a thread asking how to abort a fetch, there are tons of cases where you want to signal disinterest early - io is expensive - especially on the client and minimizing that is something that users should be able to do.

Promises have multicast semantics but are typically used in a unicast way - typically there is a single subscriber for most promises so calling `.cancel` on them aborts the request. For the cases you want multiple subscribers - you can't abort the request unless _all_ of them want to abort it without breaking the abstraction horribly and getting unsound cancellation with reject semantics.

For single subscriber cancellation is trivial with promises anyway and abort and cancellation semantics are indistinguishable. 

For multiple subscribers - abort semantics don't work with promises at a very very fundamental level, they don't fit with the abstraction. Disinterest semantics fit in quite naturally. As far as the _consumer_ is concerned they merely signal they are disinterested in the resource - if no one else is - the request for it gets aborted. If others need it - it doesn't. As a consumer - you don't have to _care_ about refcounting at all.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-176359429