The simplest example is:
```js
function doLater(callback, token) {
var handle = setImmediate(callback);
token.register(() => clearImmediate(handle));
}
var cts = new CancellationTokenSource();
doLater(..., cts.token);
cts.cancel();
```
If token registrations occur in a later turn, I have no way to clear the
handle. I can write the following instead, however:
```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.
Ron
________________________________
From: Kevin Smith <[email protected]>
Sent: Monday, March 02, 2015 6:42 PM
To: Ron Buckton
Cc: [email protected]; es-discuss
Subject: Re: Cancellation architectural observations
Cancellation
* Cancellation signals are produced by the caller and consumed by the
callee.
* Observation a cancellation signal must happen immediately.
This is a crucially important question. Can you elaborate on why you think
this is the case?
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss