Cancelable promises

Ron Buckton rbuckton at
Fri Feb 27 20:37:33 PST 2015

AsyncJS ( uses a separate abstraction for cancellation based on the .NET CancellationTokenSource/CancellationToken types. You can find more information about this abstraction in the MSDN documentation here:

From: John Lenz<mailto:concavelenz at>
Sent: ‎2/‎27/‎2015 8:01 PM
To: Andrea Giammarchi<mailto:andrea.giammarchi at>
Cc: public-script-coord at<mailto:public-script-coord at>; es-discuss<mailto:es-discuss at>
Subject: Re: Cancelable promises

On Fri, Feb 27, 2015 at 7:49 PM, John Lenz <concavelenz at<mailto:concavelenz at>> wrote:
Closure Library's promise implementation supports "cancel":

A promise is cancelled only if all the "child" promises are also cancelled.

I did not say that correctly, a "parent" promise can be cancelled by a "child" it is the only child or all the children cancel.  A parent can alway cancel its children (to the children this is simply "reject").  It does add a significant amount of complexity to the promise implementation but it is for the most part contained there.

I don't believe that "cancel" can be added after the fact and an alternative (subclass or otherwise) is needed.

On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi <andrea.giammarchi at<mailto:andrea.giammarchi at>> wrote:
AFAIK bluebird did:

But I agree once you've made Promises more complex than events ( xhr in this case ) nobody wins :-/

Although, specially for fetch or anything network related, there **must** be a way to bloody cancel that!


On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <zenparsing at<mailto:zenparsing at>> wrote:

The discussion on that github issue surrounding promise subclassing makes my head spin, especially when it comes to working out how cancelation is supposed to flow through a graph of promise dependencies.  We should be wary of adding complexity to the core.

The simple way to view the situation is to say that promises are simply transparent containers for asynchronous values. Control capabilities should therefore be represented by a separate abstraction. This will help keep complexity at the edges.

Has any library experimented with the cancelation token approach yet?

On Feb 27, 2015 1:46 AM, "Anne van Kesteren" <annevk at<mailto:annevk at>> wrote:
As a heads up, there's some debate around the fetch() API how exactly
request termination should work and how that affects promises:

The WebRTC WG has also been discussing canceling in the context of
terminating a request for permission from the user. I think they
decided to postpone for now until there's a bit more progress on what
cancelable promises means, but I would not expect everyone to wait

es-discuss mailing list
es-discuss at<mailto:es-discuss at>

es-discuss mailing list
es-discuss at<mailto:es-discuss at>

es-discuss mailing list
es-discuss at<mailto:es-discuss at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list