Cancellation architectural observations

Andrea Giammarchi andrea.giammarchi at
Fri Mar 27 16:43:49 UTC 2015

following up from this , and most
likely late to the party.

How about cancel-ability done this way ?


var p = new Promise(function (res, rej, cancel) {
  // resolved in 1 second via random value
  var t = setTimeout(res, 1000, Math.random());
  // if meant to be canceled
  // we define internally what to do
  cancel(function () {

// whenever/if needed

The exposed cancel-ability is arbitrary provided internally so that if
missing, an error is thrown while if provided it sets the internal state of
the promise as `canceled` in case it's different from `resolved` or

It gives the ability to react, if a `then` is attached, or the ability to
ignore, if nothing happens to the returned, non cancel-able, Promise.

This avoids exposing to the outer world what happens inside the Promise and
provides arbitrary ability to cancel one.

A cancel-able Promise is one that defined such behavior, which by default
is throwing if that's not defined internally.
This would solve already many cases I have in mind, via users, or
UserAgent, and legitimately behind the scene without any need to expose any
internal logic.

How to resolve or throw other attached promises? Well, `p.cancel().then()`
resolves, while `p.cancel().throw()` does not. `p.cancel()`, without then
or throw would simply throw away pending promises as explicit `ignore`

How bad does it look and what am I screwing up in here in terms of Promises

Best Regards

On Wed, Mar 4, 2015 at 8:01 PM, Ron Buckton <Ron.Buckton at>

> > new Promise(resolve => doLater(resolve, cts.token)).then(handleResult);
> > setImmediate(() => cts.cancel());
> >
> > In this scenario cancel would be called right after the resolve method
> > is called, but before handlerResult is called. For this to work with a
> > cancellation token you would need to pass the token to every step in
> > the chain to both stop work being done and to ignore the
> > result/prevent a handler from being called. Wouldn't it be better if
> > the promise chain took care of this for the programmer?
> I can be convinced that CancellationToken registrations should be invoked
> asynchronously, though I wonder if then CancellationTokenSource#cancel
> should return a Promise to observe any errors that occur.
> Ron
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list