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

Re: Cancellation architectural observations

From: Marius Gundersen <gundersen@gmail.com>
Date: Tue, 3 Mar 2015 22:41:11 +0100
Message-ID: <CAE-f-gcVWC=6f4y0T+dkdCJXeZk25B1tsX3JWx=YF2fowajd7g@mail.gmail.com>
To: Ron Buckton <rbuckton@chronicles.org>
Cc: Kevin Smith <zenparsing@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Tue, Mar 3, 2015 at 12:49 AM, Ron Buckton <rbuckton@chronicles.org>
wrote:

>  ```js
>
> function doLater(callback, token) {
>
>   setImmediate(() => {
>
>     if (token.canceled) return;
>
>     callback();
>
>   });
>
> }
>
> ```
>
>
>  But in this case, I still have a callback scheduled which may be
> unnecessary overhead. If this were a native API, we could chose to
> prioritize cancellation registrations over promise tasks. Even if the
> registrations are async, the cancellation signal would still need to be
> observable in a synchronous manner, even if only through reading the
> CancellationToken#canceled property.
>
Since cancellations are likely to be triggered asynchronously by the user,
it doesn't really matter if the cancellation signal is async or not, it
might still be too late to cancel the job. For example:

```js

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?

Marius Gundersen
Received on Thursday, 5 March 2015 12:17:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 March 2015 12:17:19 UTC