[swift-evolution] Two thoughts on concurrency

[Dave DeLong]

> On Aug 24, 2017, at 3:59 PM, Adam Kemp <adam.kemp at apple.com> wrote:
> 
> 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 <mailto: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).

That’s fine. I assumed it was blocking because it has a very prominent “wait” in the name. 🤷‍♂️ 

>> I’m admittedly not very familiar with async/await or the actor pattern.

:) 

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170824/47f229ed/attachment.html>