W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future cancellation

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 May 2013 08:21:33 -0700
Message-ID: <CAAWBYDCvAu2ziLiH8q8rfJaEJ4540mgvC9m6cttkY12d8vM-0w@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> However with this approach you get an API which automatically simply
> works as an API returning a Future in case you don't need to abort the
> operation or display its progress:
> handleResult(doSomeOperation());
> or
> return doSomeOperation();
> or
> doSomeOperation().then(val => displayResult(val));
> I.e. if you don't care about the operation part, the API simply works
> as any other API which returns a promise. This seems like a very nice
> thing. The only "cost" of this API is that it doesn't compose when you
> compose the future, but neither does the dispose object in the tuple
> approach.

The other cost is an inherent capability leak - *unless* you purposely
strip it of its cancelability, passing it around to anything else
gives the "anything else" the ability to cancel your promise as well.
The tuple approach doesn't have this issue - the promise and the
canceler/resolver are inherently separated, and you have to purposely
hand the canceler/resolver off to other code for it to have any

Received on Wednesday, 1 May 2013 15:22:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC