[Concurrency] async/await + actors: cancellation

Jan_Tuitman · August 18, 2017, 6:53am

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

shouldn't beginAsync return something which can be checked if the block passed in to it is finished/ waiting/ ...? and which has a method to cancel it?
I know Thread.cancel (which existed in some programming languages) is evil because you never know where it stops, but it seems strange to me, that there is no way to communicate with the running process in //2.

Then there is this example:

func processImageData() async throws -> Image {
  startProgressBar()
  defer {
    // This will be called when error is thrown, when all operations
    // complete and a result is returned, or when the coroutine is
    // abandoned. We don't want to leave the progress bar animating if
    // work has stopped.
    stopProgressBar()
  }

let dataResource = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  do {
    let imageTmp = try await decodeImage(dataResource, imageResource)
  } catch _ as CorruptedImage {
    // Give up hope now.
    await abandon()
  }
  return try await dewarpAndCleanupImage(imageTmp)
}

this seems to wrap other asynchronous functions in a new async function so it can add the defer logic and abandon logic, but this seems to me only adding more checking of the spawned process and thus not sufficient enough to deal with an external reason in location //3 (for example the process running //3 receives an event that the app is about to be quitted).

so I am a bit confused here, am I missing something? How would //2 be canceled from location //3, or how would //3 trigger an abandoment inside //2 ?

Jan Tuitman

dgrove-oss · August 18, 2017, 3:21pm

From: Jan Tuitman via swift-evolution <swift-evolution@swift.org>
To: swift-evolution@swift.org
Date: 08/18/2017 02:54 AM
Subject: [swift-evolution] [Concurrency] async/await + actors:

cancellation

Sent by: swift-evolution-bounces@swift.org

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

shouldn't beginAsync return something which can be checked if the
block passed in to it is finished/ waiting/ ...? and which has a
method to cancel it?
I know Thread.cancel (which existed in some programming languages)
is evil because you never know where it stops, but it seems strange
to me, that there is no way to communicate with the running process

in //2.

Then there is this example:

func processImageData() async throws -> Image {
  startProgressBar()
  defer {
    // This will be called when error is thrown, when all operations
    // complete and a result is returned, or when the coroutine is
    // abandoned. We don't want to leave the progress bar animating if
    // work has stopped.
    stopProgressBar()
  }

let dataResource = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  do {
    let imageTmp = try await decodeImage(dataResource, imageResource)
  } catch _ as CorruptedImage {
    // Give up hope now.
    await abandon()
  }
  return try await dewarpAndCleanupImage(imageTmp)
}

this seems to wrap other asynchronous functions in a new async
function so it can add the defer logic and abandon logic, but this
seems to me only adding more checking of the spawned process and
thus not sufficient enough to deal with an external reason in
location //3 (for example the process running //3 receives an event
that the app is about to be quitted).

so I am a bit confused here, am I missing something? How would //2
be canceled from location //3, or how would //3 trigger an
abandoment inside //2 ?

My initial reading is that cancellation is not part of the async/await
design. I think this is the right decision. (I hope I am right ;) ).

First the semantics of arbitrary cancellation are problematic (as you
noted); it is really hard to write reliable code when a thread of control
could be spontaneously killed at any program point but the program as a
whole still needs to be able to continue to operate). Second, support for
cancellation imposes a significant implementation burden. It implies that
you actually need to make individual tasks into real program-visible
entities and that can get in the way of high-performance implementation
techniques (which Chris alludes to as perhaps being needed in Swift 6/7/8
for an actor system to really become viable at scale).

Much more reasonable to allow the programmer to plumb in cancellation where
it is needed via shared state that can be checked at safely cancelable
points in the task.

regards,

--dave

Joe_Groff · August 18, 2017, 7:04pm

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

···

On Aug 17, 2017, at 11:53 PM, Jan Tuitman via swift-evolution <swift-evolution@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

Jan_Tuitman · August 20, 2017, 5:08am

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@apple.com> het volgende geschreven:

On Aug 17, 2017, at 11:53 PM, Jan Tuitman via swift-evolution <swift-evolution@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

snit · April 10, 2019, 4:55pm

Hey all, I'm curious about the status of the coroutines discussion. Chris Lattner has posted an interesting manifesto, but most of the topics I can on the subject seem to have lost momentum overtime. Are coroutines being considered for implementation anytime soon?

tkrajacic · April 10, 2019, 5:03pm

IIUC coroutines are already implemented, just not exposed. I think they are used for property access currently

Moximillian · April 10, 2019, 5:12pm

I don’t think other programming languages with async/await support cancel either. It’s just not part of that concept. There are many other asynchronous frameworks / concepts that are better suited for those use cases that need cancelling.