Consider listening to cancelToken's promise in the await.cancelToken spec

[domenic]

The current mechanism of tracking execution contexts is a bit weird. I did it because I thought the closure work would be weirder for the alternative. But now I am not so convinced, especially after writing Promise.withCancelToken which worked reasonably OK.

[bergus]

I already wanted to suggest that! That would be very similar to how I described CancelTokens in my proposal, btw - and I really like how they are getting closer to each other :-D.

[bergus]

Did you realise that this commit changed semantics?

[domenic]

Yes.

[bergus]

But why? Rejecting the promise immediately when you call cancel seems cleaner to me, without a asynchrony window for anything to interfere with the cancellation decision.

[domenic]

This version is actually implementable; storing execution contexts (a spec artifact) was not something that could be realistically implemented.

The difference should be barely noticeable since the await-ed promise also waits a turn. I guess we should move the waiting on the cancel token's promise to before the await-ed promise so that there's no possible way it can interfere.

[bergus]

You could have kept the old semantics by storing either the promiseCapability.[[Promise]] or the onRejected function in a list of the token, instead of the [[ExecutionContexts]]. That should've been just as implementable.

[domenic]

That's true. This version is simpler, however.