Re: Future cancellation

These are horribly confused -- and likely foot-gun -- designs.

First, synchronous resolution needs some justification. I don't understand
why you've added it in the first design. The question of "does the Resolver
know it is resolved?" is entirely independent of the visibility of that
resolution to the outside world. I don't think this flag even makes sense.

In terms of blessing one or another static method for generating the
cancellable tuple (as you do in your first two designs), why does it have
to be in the design at this point? The current design in DOM provides a
small contract to keep us from fighting over how to distinguish
cancellation from other error values (the side-contract everyone would need
to re-create at great expense), but purposefully avoids doing this for the
sake of simplicitly. I don't get why you're trying to expand this contract
in the core spec. Just subclass. Should it become so common, we can revisit
this later.

Lastly, your final design is irretrievably broken in a way the first two
aren't: it vends to anyone who has a handle to the Future the capability to
reject it.

The DOM design has studiously avoided this class of fatal design errors so
far. It's the key reason why Resolvers and Futures are separate objects. No
such design will fly in this group.

Regards

On Tuesday, April 30, 2013, Ron Buckton wrote:

>  I’ve created separate gists for three different ways that I am currently
> investigating as a means to support the cancellation of a Future. These can
> be found here:****
>
> ** **
>
> **1.       **Cancellation using Future:
> https://gist.github.com/rbuckton/5486149****
>
> **2.       **Cancellation using Future.cancelable:
> https://gist.github.com/rbuckton/5484591****
>
> **3.       **Cancellation using Future#cancel:
> https://gist.github.com/rbuckton/5484478****
>
> ** **
>
> Each has a list of some of the benefits and issues I’ve seen while
> experimenting with each approach, as well as possible changes to the
> various APIs or algorithms for Future to make each happen.****
>
> ** **
>
> In general, cancellation of a Future can be beneficial in a number of
> cases.  One example is the case where you are requesting a resource from a
> remote server using XHR. If the request was being made to fetch a page of
> data, and the user opted to move to the next page before the current page
> completed loading, it no longer becomes necessary to continue fetching the
> remote resource. In addition, it is no longer necessary to handle any
> additional computation or transformation logic that would have resulted
> from the successful completion of the fetch operation. Having the ability
> to cancel the request allows an application to quickly release resources
> that it no longer needs.****
>
> ** **
>
> It is also useful to be able to handle the cancelation of a long running
> task that might be executing in a Worker. In this case, cleanup logic that
> is part of cancelation would request the worker to close, ending the
> current operation and releasing resources.****
>
> ** **
>
> Both of the above examples are indicative of cancelling the root of an
> operation, but there are also circumstances where you might want to cancel
> a chained Future and any Future chained from it, without canceling the
> root. In the previous example regarding paged data, I might wish to allow
> the fetch operation to complete so that I could cache the data for quick
> retrieval, but would only want to cancel any possible UI updates that might
> occur in a chained Future.****
>
> ** **
>
> I’m interested to hear what others think with respect to properly handling
> cancellation with Futures. ****
>
> ** **
>
> Ron****
>