Re: Future cancellation

On Wednesday, May 1, 2013, Jonas Sicking wrote:

> On Mon, Apr 29, 2013 at 6:57 PM, Ron Buckton <rbuckton@chronicles.org<javascript:;>>
> 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.
>
> 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 is what I've sketched in various places, including for Anne WRT XHR. I
suppose (without any cause) that folks would pick up on the idea that the
minimal Future superclass was being explicitly designed to be subclassable
to address issues like this and progress notification. Perhaps we need to
call it out more explicitly in the spec?


> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org <javascript:;>
> https://mail.mozilla.org/listinfo/es-discuss
>