Future cancellation

Jonas Sicking jonas at sicking.cc
Tue Apr 30 19:47:21 PDT 2013

On Tue, Apr 30, 2013 at 5:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * 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.

"I am no longer interested in receiving this value" is definitely a
separation operation than "I want the operation to be stopped".

If you're no longer interested in receiving a particular value, that
may or may not mean that others are interested in that value. Futures
support multiple callers registering to be told about a particular
result. And, as importantly, they support people registering to
receive a result at any point in time.

If we want to support the semantics of "I am no longer interested in
receiving this value" then I propose that we add a way to "unregister"
an individual .then() callback. But I'm not at all sure that this is a
use case that is important enough to implement. Callers can always
ignore the value once it comes in.

/ Jonas

More information about the es-discuss mailing list