Future cancellation

Kevin Gadd kevin.gadd at gmail.com
Tue Apr 30 12:28:59 PDT 2013

Strongly agreed; however future cancellation should not be inferred to mean
that a task is cancelled. Rather, it means that the value the future
represents is no longer needed, which may implicitly result in the
cancellation of an actual operation.

To provide a simple example (from an actual application):
I have some stack traces from a running application, and I want to map the
individual offsets in those traces to resolved symbols. This is an
expensive operation, so I do it asynchronously.
So, I have a function that maps a given offset to a resolved symbol, with a
signature like Future<Symbol> getSymbolForOffset (uint offset). This
function returns a future that will be completed when the symbol is
Now, each one of these calls does not necessarily map to a single symbol
resolution operation - symbol resolution is expensive, so I may batch
requests up into larger groups to reduce round-trips and improve
Given this, I have a many-to-one mapping - many futures mapping to a single
operation. Simply exposing the ability to cancel that operation doesn't
make any sense; the underlying operation is an implementation detail. And,
as you mentioned, cancelling one of those futures should not cancel the
operation; the ability to cancel that operation directly should not be
exposed to an owner of just one of those futures.
Regardless, by being able to 'dispose' or mark as unneeded the individual
futures, you can ensure that if all the futures an operation is about to
fulfill are not needed, the operation can automatically be cancelled.

I see it as difficult to satisfy these scenarios without some sort of
approach to future disposal/cancellation, and I see this as separate from
questions of how one goes about cancelling tasks, even if task cancellation
is sometimes driven by future disposal/cancellation.


On Tue, Apr 30, 2013 at 12:23 PM, Kevin Smith <zenparsing at gmail.com> wrote:

> On Tue, Apr 30, 2013 at 10:26 AM, Brendan Eich <brendan at mozilla.com>wrote:
>> Lucas Smith wrote:
>>> IMO, cancelation is not appropriate for promises/futures. (sticking with
>>> the name "promises", sorry for the distraction).
>> Agreed.
> Agree as well.   More conceptually, we must not conflate *operations* with
> *results*.  "Cancel" is an action that applies to operations, not results.
> { Kevin }
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130430/17f86859/attachment.html>

More information about the es-discuss mailing list