*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 does
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
>
> 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 seman
>
> 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 futu
> 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 pr
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 cal
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 see.
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 Pro
>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. Midor
@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 "w
> 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 composi
>
> 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 a
> 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?
>
Spec-def
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() { t
>
> 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 }
> requ
> 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 tok
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 CancelError(
>
> 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 l
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
>
> 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 cancelRequest
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
> https://github.com/promises-aplus/cancellation-spec/issues/4.
>
> Data seem
>
> 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) => {
setTimeout(re
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:
-
https://books.google.com/ngrams/graph?cont
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 coming up with a new interf
>
> 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 f
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
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 cheapOperation(cancelationToken)
27 matches
Mail list logo
