[swift-evolution] Two thoughts on concurrency

Adam Kemp adam.kemp at apple.com
Thu Aug 24 16:59:00 CDT 2017


I generally agree that async/await could be more valuable built on top of library support. I did have one nitpick about this:

> On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In other words:
> 
> async func doSomething() → Value { … }
> 
> Let value = await doSomething()
> 
> Becomes sugar for this pseudocode:
> 
> func doSomething() → Future<Value> { … }
> 
> let value = doSomething().value // or however you “wait” for the value

These two examples do fundamentally different things. The await version doesn’t block the thread (it would return to the caller instead of blocking and pick up again later). The .value version would have to block. In C# this is equivalent to using the .Result property of the Task<T> type. However, that is strongly discouraged because it easily leads to deadlocks.

A closer equivalent would be something like this:

func doSomething() -> Future<Value> { … }

doSomething().continueWith { (future: Future<Value>) in
    let value = try? future.value
}

Now it’s asynchronous either way. The continuation block takes a Future<Value> so that you could do error handling (more complex error handling not shown).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170824/9e3104e6/attachment.html>


More information about the swift-evolution mailing list