W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Cancellation architectural observations

From: Ron Buckton <rbuckton@chronicles.org>
Date: Mon, 2 Mar 2015 23:49:06 +0000
To: Kevin Smith <zenparsing@gmail.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-ID: <1425340145485.86712@chronicles.org>
The simplest example is:


```js

function doLater(callback, token) {

  var handle = setImmediate(callback);

  token.register(() => clearImmediate(handle));
}


var cts = new CancellationTokenSource();

doLater(..., cts.token);

cts.cancel();

```


If token registrations occur in a later turn, I have no way to clear the handle. I can write the following instead, however:


```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.


Ron


________________________________
From: Kevin Smith <zenparsing@gmail.com>
Sent: Monday, March 02, 2015 6:42 PM
To: Ron Buckton
Cc: public-script-coord@w3.org; es-discuss
Subject: Re: Cancellation architectural observations


Cancellation

  *   Cancellation signals are produced by the caller and consumed by the callee.
  *   Observation a cancellation signal must happen immediately.

This is a crucially important question.  Can you elaborate on why you think this is the case?
Received on Monday, 2 March 2015 23:49:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 March 2015 23:49:36 UTC