Re: Cancellation architectural observations

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