Re: Promises as Cancelation Tokens

*F# cancellation* - on second thought implicit cancellation through cancellation like in F# is impractical because of the eagerness of promises. I don't think it's a valid alternative here. I've discussed this with Reed Copsey (an F# expert) and he explained the philosophy behind it to me - it

Re: Promises as Cancelation Tokens

> > For async functions, it would mean that any await expression could > potentially throw a CancelError Cancellation does not necessarily need to use `throw`, `return` is often more apt. I find. I would also recommend splitting the idea of cancellation into: abort semantics, and ignorance

Re: Promises as Cancelation Tokens

Implicit cancellation doesn't make sense if it involves a throw. Furthermore, implicit cancellation would never happen for your example - the 'await' clearly depends on the result of the operation, so it is in use and it would not make sense for it to be implicitly cancelled. For the record, every

Re: Promises as Cancelation Tokens

> > I think F#'s cancellation approach is also worth mentioning in the > discussion of alternatives as it has implicit but token-based automatically > propagating cancellation. > If you have any good links to reference materials on F#'s cancellation architecture, feel free to include them for

Re: Promises as Cancelation Tokens

> Another cancellation scenario is when the consumer of an asynchronous task no longer > needs the result of an operation. In this case, they will only have access to the Promise > unless the cancellation token is routed to them through some other path. For what it's worth - this is exactly how

Re: Promises as Cancelation Tokens

One key thing to recognize is that there are different reasons to cancel an operation and as a result, different approaches to cancellation. .NET cancellation tokens address one scenario (and do it fairly well), where the objective is for specific operations to expose cancellation and allow the

Re: Promises as Cancelation Tokens

Thanks for posting this. Great stuff! > On a page that loads 100 images four at a time, you would want 4 cleanup > actions registered, not 100. > And in order to keep it to 4 you need a way to unregister the action when you complete the operation, which the promise API doesn't give you. I

Re: Promises as Cancelation Tokens

Thanks Ron! Comments inline... > · Once a callback has been registered for asynchronous notification > of a cancellation signal, it can later be unregistered. > Yes, I see how this could be helpful. > · Asynchronous notifications are queued and handled at a higher > priority than

Re: Promises as Cancelation Tokens

Since checking `promise.state` is synchronous, we may as well just write a synchronous Cancel class instead: ```js class CancelError extends Error { /* ... */ } class Cancel { constructor() { this.requested = false } request() { this.requested = true } throw() { throw new

Re: Promises as Cancelation Tokens

Cool, yeah, the reveal pattern would indeed be a good way to guard against unwanted/unexpected cancels. ```js class Cancel { constructor(executor) { this._requested = false executor(() => this._requested = true) } get requested() {return this._requested} throw() {

Re: Promises as Cancelation Tokens

> > Since checking `promise.state` is synchronous, we may as well just > write a synchronous Cancel class instead: > Right - see upthread. You do need some kind of callback method, though, like `whenCancelled(callback)`. > class Cancel { > constructor() { this.requested = false } >

Re: Promises as Cancelation Tokens

> > We have pretty sound cancellation semantics in bluebird 3. > Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. ___ es-discuss mailing

Re: Promises as Cancelation Tokens

> > The best approach in cases like this is to avoid the word altogether. > The fact that there's confusion at all means people will mess it up > and get annoyed, even if there's a "winner" in overall usage. > Hmmm... Maybe class CancelToken { constructor(init); get

Re: Promises as Cancelation Tokens

We have pretty sound cancellation semantics in bluebird 3. http://bluebirdjs.com/docs/api/cancellation.html Handles multiple subscribers soundly. Solves the common use cases pretty well - has absolutely zero magic and pretty simple semantics. They work with .all and .race too. We have had a

Re: Promises as Cancelation Tokens

> Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. Cool, re-reading the discussion you asked for this in the first message - I apologize for missing it. I think using promises as

Re: Promises as Cancelation Tokens

> We could use a promise subclass as the cancellation token, but then tokens (and their constructor) would inherit things that really don't make sense, like "CancelToken.resolve" and "CancelToken.prototype.catch". Generally I dislike inheritance. I was merely saying it's an option. I favor

Re: Promises as Cancelation Tokens

> > I think using promises as tokens would be problematic. It would have > several issues: > Agreed with all of those. It's also important to keep in mind that promises can be subclassed so it's > fine to add properties to them if used for a specific purpose like > cancellation. > We could use

RE: Promises as Cancelation Tokens

@domenic.me> Cc: es-discuss<mailto:es-discuss@mozilla.org> Subject: Re: Promises as Cancelation Tokens The best approach in cases like this is to avoid the word altogether. The fact that there's confusion at all means people will mess it up and get annoyed, even if there's a "winner"

Re: Promises as Cancelation Tokens

>From experience, I'm very much in favor of the cancellation token. Though promises provide a good inspiration for cancellation, they don't quite fit the problem directly. The approach has been explored, though the details are not published. I implemented cancellation for the Midori system.

Re: Promises as Cancelation Tokens

> throw() { throw new CancelError() } > This should be `throwIfRequested` I think, e.g. throwIfRequested() { if (this._requested) throw new CancelError(); } } > What would be the recommended way of keeping the internal state > private? With a WeakMap? >

Re: Promises as Cancelation Tokens

On Mon, Jan 4, 2016 at 9:01 AM, Domenic Denicola wrote: > From: Kevin Smith [mailto:zenpars...@gmail.com] > >> And what's the deal, is it canceled or cancelled? : ) > > This is kind of the worst. Previous discussion at >

Re: Promises as Cancelation Tokens

> > I am also unsure when .whenCanceled is necessary > Maybe in the case where you have a promise-returning function and you want to reject the returned promise upon cancellation. function delayWithCancel(ms, cancelToken) { return new Promise((resolve, reject) => {

Re: Promises as Cancelation Tokens

I agree that without synchronous inspection cancellation tokens become very hard to deal with as you may be queued for a long time prior to cancellation on the event loop, and then the operation is cancelled while you are waiting to check for cancellation. Is there a reason to use a Promise as the

Re: Promises as Cancelation Tokens

And what's the deal, is it canceled or cancelled? : ) On Mon, Jan 4, 2016 at 11:30 AM Kevin Smith wrote: > Is there a reason to use a Promise as the cancellation token, rather than >> have something that is synchronously inspectable? >> > > The only real downside of

RE: Promises as Cancelation Tokens

In general I agree that there is a nice conceptual symmetry, but IMO the day-to-day impedance mismatch would be simply too great. Compare: ```js async function f(cancelationToken) { cancelationToken.then(() => console.log("FYI you have been canceled")); await

Re: Promises as Cancelation Tokens

> > Is there a reason to use a Promise as the cancellation token, rather than > have something that is synchronously inspectable? > The only real downside of coming up with a new interface is that we have to standardize it. : ) It's a core protocol. I agree that using a promise directly would

RE: Promises as Cancelation Tokens

From: Kevin Smith [mailto:zenpars...@gmail.com] > And what's the deal, is it canceled or cancelled?  : ) This is kind of the worst. Previous discussion at https://github.com/promises-aplus/cancellation-spec/issues/4. Data seems to favor cancelled: -