The upside of having a separate abstraction for cancellation, is that it
composes well with async functions:
```js
async function runStockTicker(receiveSymbol, cancellationToken) {
while (!cancellationToken.canceled) {
var symbols = await fetchSymbols(cancellationToken);
if (!cancellationToken.canceled) {
for (var symbol of symbols) {
receiveSymbol(symbol);
}
await sleep(1000);
}
}
}
var stopTicker = new CancellationTokenSource();
runStockTicker(..., stopTicker.token);
...
stopTicker.cancel(); // stop the current fetch and the loop
```
Ron
________________________________________
From: es-discuss <[email protected]> on behalf of Tab Atkins Jr.
<[email protected]>
Sent: Monday, March 02, 2015 6:21 PM
To: Kevin Smith
Cc: [email protected]; Dean Tribble; es-discuss
Subject: Re: Cancellation architectural observations
On Mon, Mar 2, 2015 at 3:18 PM, Kevin Smith <[email protected]> wrote:
> I'm afraid I don't quite understand. How is one supposed to create a
> cancelable task with async functions, under your proposed architecture?
I'm not sure! The mapping between promises and async functions isn't
intuitive to me yet, and I'm not sure how async functions will be able
to produce promise subclasses rather than plain promises.
~TJ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
