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

Re: Future cancellation

From: Bill Frantz <frantz@pwpconsult.com>
Date: Wed, 1 May 2013 05:50:09 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
cc: Brendan Eich <brendan@mozilla.com>, public-script-coord@w3.org, es-discuss <es-discuss@mozilla.org>
Message-ID: <r422Ps-1075i-6E5A78CC36A445C08CB34B6741AB5F29@Williams-MacBook-Pro.local>
[General comments here, specifics inline.]

My experiences with promises is as an E programmer. When they 
are used pervasively in an application the graph can get as 
messy as the reference graph of an object oriented program. For 
languages with objects and references, garbage collection became 
the generally accepted way of cleaning up the mess (c.f. C++). 
For promises, breaking the promise allows the graph to be 
cleaned up.

On 4/30/13 at 11:04 PM, jackalmage@gmail.com (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.
>
>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.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032
Received on Wednesday, 1 May 2013 12:50:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC