rbuckton at chronicles.org
Tue Apr 30 17:42:26 PDT 2013
As I mentioned to Alex Russel, I'm also interested in the benefits of using a subclass. I have two additional gists around cancellation, one that uses an external token for cancelation  (similar to .NET/C#), and another that uses a subclass  (though I still need to spend some additional time on the subclass sample).
I agree with the sentiment that Future#cancel is a bad idea.
> -----Original Message-----
> From: Jonas Sicking [mailto:jonas at sicking.cc]
> Sent: Tuesday, April 30, 2013 4:47 PM
> To: Ron Buckton
> Cc: es-discuss; public-script-coord at w3.org; Tab Atkins Jr.
> Subject: Re: Future cancellation
> On Mon, Apr 29, 2013 at 6:57 PM, Ron Buckton <rbuckton at chronicles.org>
> > 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.
> I do not think that we should add cancellation on the base Future interface. I.e.
> we shouldn't make *all* Futures cancellable.
> Cancelability should only be possible when the implementation of the Future
> would actually stop doing work if the Future is cancelled. I.e.
> cancelling a Future shouldn't simply prevent the result callbacks from being
> called, but it should prevent whatever work is needed to calculate the result
> from happening.
> However it would be very complex and expensive if we had to make all APIs
> that want to use Futures also support being cancelled.
> The solution is to create a subclass of Future which allows the back-end work to
> be cancelled. I.e. a CancelableFuture, or AbortableFuture. This subclass would
> have a .cancel() or .abort() method on it. The FutureResolver created when the
> CancelableFuture is created would have a callback which is called when
> .cancel()/.abort() is called.
> This would be useful if we create an Future-based API for doing network
> requests or file reading.
> In other words, the should be the choice of the implementor of a given API to
> determine if it wants to return a Future which can be cancelled, or one that
> can't. Obviously this needs to be documented for that API, just like you
> document that the API returns a Future at all.
> / Jonas
More information about the es-discuss