[swift-evolution] [Concurrency] async/await + actors: cancellation

[Jan Tuitman]

Hi Joe,

Thanks for the answers so far! 

Abrupt cancellation is indeed not a good idea, but I wander if it is possible on every place where “await” is being used, to let the compiler generate  code which handles cancellation, assuming that can be cheap enough (and I am not qualified to judge if that is indeed the case)

Especially in the case where “await” implies “throws”, part of what you need for that is already in place. I imagine that it would work like this:
I imagine f(x) -> T is compiled as something that looks like f(x, callback: (T) -> Void). What if this was f(x,process, callback) where process is a simple pointer, that goes out of scope together with callback? This pointer the compiler can use to access a compiler generated mutable state, to see if the top level beginAsync { } in which context the call is being executed, has been canceled. The compiler could generate this check whenever it is going to do a new await call to a deeper level, and if the check said that the top level is canceled, the compiler can throw an exception. 

Would that introduce too much overhead? It does not seem to need references to the top level any longer than the callback needs to be kept alive.

I am asking this, because once Async/await is there, it will probably immediately become very popular, but the use case of having to abort a task from the same location where you start the task, is of course a very common one. Think of a view controller downloading some resources and then being moved of the screen by the user.

if everybody needs to wrap Async/await in classes which handle the cancellation, and share state with the tasks that can be cancelled, it might be cleaner to solve this problem in an invisible way, so that it is also standardized. This way there is more separation between the code of the task and the code that starts and cancels the task.

I assume actors in the future also are going to need a way to tell each other that pending messages can be cancelled, so, I think, in the end you need something for cancellation anyways. 

For the programmer it would look like this:

var result ....
var process = beginAsync {
   result = await someSlowFunctionWithManyAwaitsInside(x)

}

// if it is no longer needed.
process.cancel()
// this will raise an exception inside someSlowFunction if this function enters an await.
// but not if it is waiting or actively doing something. So, it is also not guaranteed to cancel the function.



Regards,
Jan



> Op 18 aug. 2017 om 21:04 heeft Joe Groff <jgroff at apple.com> het volgende geschreven:
> 
> 
>> On Aug 17, 2017, at 11:53 PM, Jan Tuitman via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hi,
>> 
>> 
>> After reading Chris Lattners proposal for async/await I wonder if the proposal has any way to cancel outstanding tasks.
>> 
>> I saw these two:
>> 
>> @IBAction func buttonDidClick(sender:AnyObject) {
>> // 1
>> beginAsync {
>>  // 2
>>  let image = await processImage()
>>  imageView.image = image
>> }
>> // 3
>> } 
>> 
>> 
>> And:
>> 
>> /// Shut down the current coroutine and give its memory back to the
>> /// shareholders.
>> func abandon() async -> Never {
>> await suspendAsync { _ = $0 }
>> }
>> 
>> 
>> Now, if I understand this correctly, the second thing is abandoning the task from the context of the task by basically preventing the implicit callback of abandon() to ever be called.
>> 
>> But I don't see any way how the beginAsync {} block can be canceled after a certain amount of time by the synchronous thread/context that is running at location //3
> 
> This is not something the proposal aims to support, and as you noted, abrupt cancellation from outside a thread is not something you should generally do, and which is not really possible to do robustly with cooperatively-scheduled fibers like the coroutine proposal aims to provide. The section above is making the factual observation that, in our model, a coroutine once suspended can end up being dropped entirely by releasing all references to its continuation, and discusses the impact that possibility has on the model. This shouldn't be mistaken for proper cancellation support; as David noted, that's something you should still code explicit support for if you need it.
> 
> -Joe
>