- From: jhusain <notifications@github.com>
- Date: Mon, 30 Mar 2015 08:43:39 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/27/87727561@github.com>
This is a very reasonable concern in principle, but in my experience is not a problem in practice. Perhaps this is a matter of not clearly defining what I mean by producer and consumer. In this context by producer I mean "fetch" which controls the code which backs the Task. By consumer I mean the code that assigns a callback to a Task and receives a subscription which can be used to stop listening for the result: var task = fetch(...); var subscription = task.get(value => console.log(value), error => console.error(error)); // subscription.dispose() can be used to stop listening In this context the producer (fetch) does not cancel unless there are no more consumers. Fetch doesn't have sufficient context to cancel a request. As for garbage collection, disposing of the subscription removes the reference from the task to the handlers passed to get. This breaks the link and allows GC to occur. Can you clarify what you mean by producer? All application use cases I have encountered in UIs can be accommodated with the notion of consumer unsubscription. An event may occur which may cause a consumer to stop listening for the result of a task, such as a form being closed. In these situations it can be the consumers responsibility to explicitly unsubscribe from a Task when events occur which cause their eventual data to become irrelevant. This can even be done declaratively with compositional functions as in the example below: var task = fetch(...); var subscription = task. until(formClosed). // another Task or Promise get(value => console.log(value), error => console.error(error)); JH > On Mar 30, 2015, at 5:21 PM, Kyle Simpson <notifications@github.com> wrote: > > If all consumers stop listening for the outcome > > The problem I see with this implicit GC-directed version of cancelation is that the producer very quickly stops being in control of who is observing the outcome of the task. If you make a fetch(..) call, and pass its promise/Task/whatever return value around to multiple observers, and then something critical happens and you (the producer) decide you need to cancel the fetch(..) (abort an upload b/c user goes offline, etc), you can't, because you can't reach into all those possible places where observers attached and get all of them to cancel(..) or ignore(..) or even just unset themselves for GC purposes. > > Also, GC is not guaranteed to happen as soon as all refs are unset. If you want to abort a fetch(..) right now, and you unset all observers, the engine may not GC all those for seconds or more, which means the abort may very well not happen immediately. > > — > Reply to this email directly or view it on GitHub. > --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/27#issuecomment-87727561
Received on Monday, 30 March 2015 15:44:11 UTC