W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Cancellation architectural observations

From: Andrea Giammarchi <andrea.giammarchi@gmail.com>
Date: Fri, 27 Mar 2015 17:43:49 +0100
Message-ID: <CADA77mhAY8=QY3mT4iCN=fvRpmWRaQbWwpKAxwvWgqyYLfpr5g@mail.gmail.com>
To: Ron Buckton <Ron.Buckton@microsoft.com>
Cc: Marius Gundersen <gundersen@gmail.com>, Ron Buckton <rbuckton@chronicles.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
following up from this
https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , 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@microsoft.com>

> > 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
Received on Friday, 27 March 2015 16:44:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC