Re: Future cancellation

On Wed, May 1, 2013 at 5:50 AM, Bill Frantz <> wrote:
> On 4/30/13 at 11:04 PM, (Tab Atkins Jr.) wrote:
>> Every future is "cancellable" already.  If you hand out your resolver,
>> anyone with it can preempt you and (prematurely?) fulfill the promise,
>> before your intended code-path finishes.  There are only two small
>> differences between normal promises and ones that are explicitly
>> "cancellable":
> This comment seems to be the essence of the issue. You can hold the resolver
> at the edge of a abortable computation. When you decide to abort the
> computation, perhaps because one or more consumers have indicated they are
> no longer interested in the results, you can use the resolver to resolve the
> promise as "broken". That broken promise will filter up through all
> computations which depend on it's value, allowing them to proceed knowing
> that the value will not be produced.

I think it's reasonably valuable to allow cancelers to choose whether
to cancel the computation with an error, or to cancel it with another
value.  For example, you could race an XHR promise and a timeout
promise, and if the timeout finishes first, it cancels the XHR with a
default value.

(Hm, on the other hand, this use-case is already taken care of by
Future.any(), especially if we spec that Future.any() auto-cancels any
cancellable futures passed to it if they don't resolve in time.)

>> 1. Some promises are holding onto resources (locks, network
>> connections, cpu time) which will be disposed of when they're
>> finished.
> I think this statement is wrong. Promises don't hold resources. They are a
> placeholder for a value to be provided later. Perhaps the computation which
> may provide the value at some future time holds a resource, or the
> computation which will consume the value when it is resolved holds a
> resource (generally a poor programming practice), but the promise itself
> doesn't hold resources.

Semantics.  ^_^  The promise can represent a computation, which can
hold some releasable resources.


Received on Wednesday, 1 May 2013 14:54:54 UTC