Re: Cancellation architectural observations

El 03/03/2015 22:42, "Marius Gundersen" <gundersen@gmail.com> escribió:
>
>
>
> On Tue, Mar 3, 2015 at 12:49 AM, Ron Buckton <rbuckton@chronicles.org>
wrote:
>>
>> ```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.
>
> Since cancellations are likely to be triggered asynchronously by the
user, it doesn't really matter if the cancellation signal is async or not,
it might still be too late to cancel the job. For example:
>
> ```js
>
> new Promise(resolve => doLater(resolve, cts.token)).then(handleResult);
> setImmediate(() => cts.cancel());
> ```
> In this scenario cancel would be called right after the resolve method is
called, but before handlerResult is called. For this to work with a
cancellation token you would need to pass the token to every step in the
chain to both stop work being done and to ignore the result/prevent a
handler from being called.

It is not necessary, if you don't care about the result as Dean pointed at
the beginning of the thread, and the promise is already resolved, let's be
it while if it is not resolved, the implementation could never call
acceptance or rejection callbacks and this way, the promise is effectively
prevented from calling any further callback.

>Wouldn't it be better if the promise chain took care of this for the
programmer?

Cancellation is a feature of the value, not of the promise itself. The
value should follow a cancelable architecture. I.e. `fetch()` will resolve
almost immediately with a value not representing a `response` but a
`cancellableProcess` then it could offer a `.cancel()` method, a
`.isCancelled` flag and a `.response()` method which resolve in the actual
`response`, rejects if network error or never resolves if the flag is true.

>
> Marius Gundersen
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>