Add possibility to truly cancel/dispose Fututre

[anowakiteo]

Hi,
In current version of dart there is possibility to cancel Future, using CancelableOperation. But this solutions do only one thing, cancels listening for result.

There is missing possibility to truly cancel working Future.

Eg. This small piece of code will run, even all futures are canceled:

 for (int j = 0; j < 10; j++) {
    Future<void> longOne = () async {
      await Future.delayed(Duration(seconds: 1));
      int i = 0;
      int b = 0;
      Random c = Random(j);
      while (++i < 42949672) {
        b = c.nextInt(i);
      }
      print("Debug: index: $j");
      return;
    }().timeout(Duration(milliseconds: 100)).catchError((e) {
      print(e);
    });
    CancelableOperation cancelableOperation = CancelableOperation.fromFuture(longOne, onCancel: () {
      print("cancel called");
    });
    cancelableOperation.cancel();
  }

output:

cancel called
cancel called
cancel called
cancel called
cancel called
cancel called
cancel called
cancel called
cancel called
cancel called
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
TimeoutException after 0:00:00.100000: Future not completed
Debug: index: 0
Debug: index: 1
Debug: index: 2
Debug: index: 3
Debug: index: 4
Debug: index: 5
Debug: index: 6
Debug: index: 7
Debug: index: 8
Debug: index: 9

[lrhn]

There is no cancel on Future because the Future value represents the result of an asynchronous computation, not the computation itself. It's a value object, is immutable (from the outside) and it can be safely shared.

The code above is not cancelling any futures. It's cancelling a cancelable operation, but you forgot to link the onCancel callback to the code that you wanted to cancel. That would be something like:

for (int j = 0; j < 10; j++) {
    bool isCancelled = false;
    Future<void> longOne = () async {
      await Future.delayed(Duration(seconds: 1));
      if (isCancelled) return;
      int i = 0;
      int b = 0;
      Random c = Random(j);
      while (++i < 42949672) {
        b = c.nextInt(i);
      }
      print("Debug: index: $j");
      return;
    }().timeout(Duration(milliseconds: 100)).catchError((e) {
      print(e);
    });
    CancelableOperation cancelableOperation = CancelableOperation.fromFuture(longOne, onCancel: () {
      print("cancel called");
      isCancelled = true;
    });
    cancelableOperation.cancel();
  }

That's how a CancelableOperation is intended to be used.

To change futures so that they can be cancelled directly, and make the future represent the entire computation would be a significant change.
Sharing the future would no longer be safe if everybody with access can cancel the operation for everybody else. We'd probably want to enforce "single ownership", perhaps by making the future only accept a single listener for its result.
Alternatively, there will be "uncancellable" wrapped futures which ignore their cancel, or "reference counted" futures where cancels are ignored until all "owners" have cancelled. A much more complex concept.

There would need to be some kind of onCancel callback on Completers. That's fairly easily doable. Code would then be expected to check for that. A then/catchError would propagate cancels. They would probably need a callback too, so future.then(something(value), onCancel: () { ...}), since there is no Completer here. An async function would also need a way to know whether it's cancelled or not, maybe just a single boolean isCancelled made available somehow.

All in all, definitely more complicated, and not something that an be compiled directly to JavaScript promises.

[anowakiteo]

The code above is not cancelling any futures. It's cancelling a cancelable operation, but you forgot to link the onCancel callback to the code that you wanted to cancel. That would be something like:

This was intented as a showcase :)

So in that moment the only way to somehow stop "Future operations" is move computation into new isolate, am I right?

[lrhn]

Yes, an isolate is the only kind of computational unit that you can actually cancel from the outside in Dart.
There is no way to cancel a single "computation" in an isolate unless it is cooperating, because it is not a well-defined unit from the language's perspective.

[MatrixDev]

You cannot use CancelableOperation everywhere. This removes any benefits of async/await syntax (not even taking to account nested awaits). It also very hard to wrap everything when multiple await calls are happening as it will lead to spaghetti callbacks code.

Frankly, I'm a little surprised that if was not foreseen when designing async/await. This cancellation really limits where await can be used.

It would be really nice to implement something like cancelable coroutines in Kotlin (or Tasks in C#). They just throw CancellationException on suspension points (aka await calls). This greatly helps with resource cleanup when no-one needs it anymore.

[lrhn]

That's basically what async* streams and await for are doing.
An async* function runs until a yield-point, then emit a value that other code can use. If that other code is an await for loop, the original code is paused at the yield point until the other code is ready for a new event. If the other code decides it doesn't want more events, it can cancel, and the original code will break out at the yield point (it'll return rather than throw, but it still bails out).

The future async/await combination is not intended for that kind of control. There is no yield points to break at, and allowing a cancellation at any asynchronous break is highly fragile.

[MatrixDev]

await for is a completely different thing as it is mostly used for async iteration. Moreover it will not cancel nested awaits when Stream is unsubscribed.

I'm talking about complex logic with multiple nested awaits that can't be moved to a await for loop, like awaiting results from different objects at different point of time:

Future<void> doSomething() async {
   // some logic here
   await cloudApi.getFromSomewhere() // additional awaits might happen inside
   // do something else
   await databaseApi.someEvent() // additional awaits might happen inside
   // do more stuff
   await ... // for multiple futures here
   // etc.
}

How is coroutines cancellation in Kotlin or tasks in C# fragile?
await itself can be "yield" point (or whatever you name it) at which exceptions can be thrown (or special Dart-internal value returned and handled appropriately).

[lrhn]

When we designed async and await, we found that having aborts occur at arbitrary locations (and await in an async function is rather arbitrary - it's driven by whether the code you call is async, not your own choices) makes it very hard to reason about the correctness of the code.
Originally, an async* function was specified to be able to abort at both yield and await if the stream was cancelled.
The example that prompted that to be changed was:

Future resourceUser() async* {
  var resource = await allocateResource();
  try {
    ...do something with resource ...
    ... yield something ...
  } finally { 
    resource.release();
  }
}

This code is currently safe. If the allocation fails, the code throws. If the allocation succeeds, the code enters the try/finally block, and the resource is guaranteed to be released again.
If the await itself could choose to throw or exit the function, then the resource could be allocated and never released.
Being able to "abort" at arbitrary points in user code means that the user code will lose control of the computation at that point.

Even if cancelling at the await would also recursively cancel the allocation of the resource, there could still very easily be race conditions where the resource has been allocated, but the await has not gotten around to deliver the value yet. This is asynchronous code after all. Ensuring that that could not happen would mean that calling cancel on the future would need to be able to respond whether that's possible. A completed future is not cancellable any more, so you could get into situations where an await inside a cancelled operation must still not bail out, because it can't recursively cancel the awaited future any more. This gets complicated fast.

The current design for futures is not intended to solve cancelling. It never was, even before adding async/await syntax ("when designing async/await" was not when futures were designed, they predate the syntax by some time). If you need to cancel an operation, you need to cooperate with it. It's simple, but that also makes it very easy to understand: You get a future, it will eventually complete, and that is all.

Could we have done differently from the start? Probably. We could have added bool cancel() to futures, and an set onCancel(bool cancel()) callback on Completer where the callback returns true if cancellation would succeed.
That would essentially have made futures non-sharable (don't want to give people the chance to cancel futures for each other). We'd probably only have allowed you to listen to a future once, then (no sharing means no need to support sharing).
Then with async/await, cancelling the future of the async function would recursively cancel any future currently being await'ed (if it can still be cancelled, otherwise the outer cancel fails too). if successful, the await would throw a CancelError. It would also similarly cancel-and-throw if the function is blocked at an await for or yield (this is always possible, it doesn't have to recursively cancel any futures), and finally complete the original future with the result of the function.
(Which means that if you catch the CancelError or use a finally, the code might keep running. We'd have to say that any await after a cancel would immediately try to cancel its future - which can fail - and await for/yield would immediately throw too, to avoid starting new computations). Complicated, but possibly workable.

That's just not what the goal of Future was when it was designed. Maybe it should have been, but I don't see us changing that now.

[mraleph]

The problem is not propagating cancellation upwards (await already would throw if the Future it waits for completes with error), it is propagating it downwards - for which there is no mechanisms right now, e.g.

Future<void> foo() async {
  await bar();
}

Future<void> bar() async {
  await baz();
}

Future<void> baz() async {
  // ...
}

void main() {
  foo().cancel();
}

Here cancellation should propagate from downwards all the way to Future produced by baz which should then complete with Error.

It is not clear to me if there is anything prevents us from defining the following semantics:

1. async functions produce CancellableFuture<T> which extends normal Future<T> interface with cancel method.
2. When cancel is called if underlying async method is paused on await point and value that is being awaited is CancellableFuture<T> propagate cancel to that future. If awaited value is not CancellableFuture then simply treat this await as if underlying future completed with CancellationError. If method is paused on await for - cancel subscription instead (this point might need tweaking).

I would assume this is what Kotlin does.

UPDATE: an example with allocateResource above illustrates potential source of breakage when introducing cancellation.

[MatrixDev]

@mraleph, at very least minimal api to check whether current Future async chain is cancelled would be really nice. That way developers can design "interruption" points themself. For ex.

Future<void> doSomething() async {
  // do some stuff
  if (isAsyncCancelled) return
  // do some other stuff
}

isAsyncCancelled is a really lightweight alternative to the coroutineContext.isActive from Kotlin that can be accessed only from async functions. All old code will still work, nothing will break. But it will be possible to manually check for future cancellation at "safe" points.

[lrhn]

We could add magic and let doSomething.isCancelled be special-cased inside the invocation of the async function doSomething itself. That way, if you have more than one nested async function, you can check the correct one, and we won't have to insert extra names into the scope (which would be both breaking and confusing).

The idea of introducing CancellableFuture as a new interface, and make all existing platform Futures implement that, might work. I fear that it just means that we'll just end up adding extension CancelFuture<T> on Future<T> { bool cancel() => (this as CancellableFuture<T>).cancel(); }, and nobody will actually check whether their future is a CancelableFuture becasue "they all are" (except when they're not).
It would be nicer if we could add cancel on Future itself, but that will likely require interface default methods.

[MatrixDev]

@lrhn yeap, it would be great!

But there is still a question regarding nested cancellation mentioned by @mraleph.
baz.isCancelled should return true when foo is cancelled. Otherwise it will not be possible to properly cancel a tree of futures.