[swift-evolution] [Concurrency] Async/Await

[BJ Homer]

Your processImageData1() function is not asynchronous, and does not need to return a future, because the “.get” calls are blocking; as you have implemented them, they will wait until they have a response or timeout. As a result, by the time you reach the return imageResult line, you have already waited for that data (or timed out), with the current thread blocked. There is no work left to do in the Future.

The point of async/await is that we can wait for the completion of those items asynchronously, not blocking the current thread. The control would return to the calling function before all the data was fetched.

-BJ

> On Aug 23, 2017, at 7:35 PM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi All,
> 
> Really glad that concurrency is on the table for Swift 5.
> 
> I am not sure if async/await are worth adding, as is, to Swift because it is just as easy to do with a library function - in the spirit of Swift 5, see `Future` library code below that you can play with and run.
> 
> If a `Future` class was added and the compiler translated 'completion-handler' code to 'future' code then the running example given in the whitepaper would become (also see the example in the code below):
> 
> func loadWebResource(_ path: String) -> Future<Resource> { ... }
> func decodeImage(_ dataResource: Resource, _ imageResource: Resource) -> Future<Image> { ... }
> func dewarpAndCleanupImage(_ image: Image) -> Future<Image> { ... }
> 
> func processImageData1() -> Future<Image> {
>     let dataResource  = loadWebResource("dataprofile.txt") // dataResource and imageResource run in parallel.
>     let imageResource = loadWebResource("imagedata.dat")
>     let imageTmp      = decodeImage(dataResource.get ?? Resource(path: "Default data resource or prompt user"), imageResource.get ?? Resource(path: "Default image resource or prompt user"))
>     let imageResult   =  dewarpAndCleanupImage(imageTmp.get ?? Image(dataPath: "Default image or prompt user", imagePath: "Default image or prompt user"))
>     return imageResult
> }
>  
> Which I would argue is actually better than the proposed async/await code because:
> The code is naturally parallel, in example dataResource and imageResource are calculated in parallel. 
> The code handles errors and deadlocks by providing a default value using `??`.
> The code can be deadlock free or can help find deadlocks, see code below, due to having a timeout and a means of cancelling.
> The programmer who writes the creator of the `Future` controls which queue the future executes on, I would contend that this is the best choice since the programmer knows what limitations are in the code and can change queue if the code changes in later versions. This is the same argument as encapsulation, which gives more control to the writer of a struct/class and less control to the user of the struct/class.
> In summary, I don't think async/await carries its weight (pun intended), as it stands, compared to a library.
> 
> But definitely for more Swift concurrency,
> 
>  -- Howard.
> 
> PS A memory model and atomic that also guaranteed volatile would really help with parallel programming!
> 
> …(snip)...
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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