Re: Future cancellation

* Jonas Sicking wrote:
>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.

You seem to be arguing based on the word "cancel". The semantic would
rather be "Please note that I am no longer interested in this value",
which would make sense even if the "work" is not actually "stopped",
and, accordingly, it would not be complex and expensive to support.

In other words, I think most people would agree that a "forced stop"
option for everything is complex and expensive and should not be re-
quired, but that does not necessarily invalidate the ideas that moti-
vate a "cancel" option.

>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.

"Future" "subclasses" seem rather dubious to me.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 1 May 2013 00:56:59 UTC