Future cancellation

Tab Atkins Jr. jackalmage at gmail.com
Wed May 1 11:13:46 PDT 2013

On Wed, May 1, 2013 at 11:04 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
> On 5/1/13 at 7:54 AM, jackalmage at gmail.com (Tab Atkins Jr.) wrote:
>> On Wed, May 1, 2013 at 5:50 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
>>> On 4/30/13 at 11:04 PM, jackalmage at gmail.com (Tab Atkins Jr.) wrote:
>> ...
>>>> 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.
> To my mind this is an important distinction. The promise does not represent
> the computation. It represents the result.
> Any representation of the computation itself bring in a whole lot baggage
> which includes, the problem of managing distributed computation in the cloud
> plus a lot of other issues. Dragging this stuff into the base level of a
> programming language is a bad crossing of abstraction levels.

I think you're making this far too complicated.  It's much simpler than this:

1. XHR is a very reasonable API to Future-ize.
2. XHRs are cancellable.
3. Ergo, we should have a cancellable Future subtype.


More information about the es-discuss mailing list