Maybe this will be handled more gracefully via the actor model.
1. if you're calling from an actor, you'd be called back on its internal queue.
If you're calling from the 'main actor' (or just the main thread), you'd be
called back on the main queue
2. you would just add a cancel() method to the actor
3. the processImage() method would call suspendAsync() and store the
continuation block in an array, once the result is available it would call all
the continuation blocks with the result
That would only work if we're able to send messages to the actor while previous
messages to processImage() are pending. That's something that's not yet clear
to me if actors can work that way.
Thomas
> On 19 Aug 2017, at 13:56, Jakob Egger via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I've read async/await proposal, and I'm thrilled by the possibilities. Here's
> what I consider the canonical example:
> @IBAction func buttonDidClick(sender:AnyObject) {
> beginAsync {
> let image = await processImage()
> imageView.image = image
> }
> }
> This is exactly the kind of thing I will use async/await for!
>
> But while this example looks extremely elegant, it would suffer from a number
> of problems in practice:
>
> 1. There is no guarantee that you are on the main thread after `await
> processImage()`
> 2. There is no way to cancel processing
> 3. Race Condition: If you click the button a second time before
> `processImage()` is done, two copies will run simultaneously and you don't
> know which image will "win".
>
> So I wondered: What would a more thorough example look like in practice? How
> would I fix all these issues?
>
> After some consideration, I came up with the following minimal example that
> addresses all these issues:
> class ImageProcessingTask {
> var cancelled = false
> func process() async -> Image? { … }
> }
> var currentTask: ImageProcessingTask?
> @IBAction func buttonDidClick(sender:AnyObject) {
> currentTask?.cancelled = true
> let task = ImageProcessingTask()
> currentTask = task
> beginAsync {
> guard let image = await task.process() else { return }
> DispatchQueue.main.async {
> guard task.cancelled == false else { return }
> imageView.image = image
> }
> }
> }
> If my example isn't obvious, I've documented my thinking (and some
> alternatives) in a gist:
> https://gist.github.com/jakob/22c9725caac5125c1273ece93cc2e1e7
> <https://gist.github.com/jakob/22c9725caac5125c1273ece93cc2e1e7>
>
> Anyway, this more realistic code sample doesn't look nearly as nice any more,
> and I actually think this could be implemented nicer without async/await:
>
> class ImageProcessingTask {
> var cancelled = false
> func process(completionQueue: DispatchQueue, completionHandler:
> (Image?)->()) { … }
> }
> @IBAction func buttonDidClick(sender:AnyObject) {
> currentTask?.cancelled = true
> let task = ImageProcessingTask()
> currentTask = task
> task.process(completionQueue: DispatchQueue.main) { (image) in
> guard let image = image else { return }
> guard task.cancelled == false else { return }
> imageView.image = image
> }
> }
>
> So I wonder: What's the point of async/await if it doesn't result in nicer
> code in practice? How can we make async/await more elegant when calling from
> non-async functions?
>
>
> Jakob
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
