[swift-evolution] [Concurrency] Async/Await

[Howard Lovatt]

You are correct, my mistake. Example should read:

func processImageData1() -> Future<Image> {
    return AsynchronousFuture { _ -> Image in
        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.get ?? Image(dataPath: "Default image or prompt
user", imagePath: "Default image or prompt user")
    }
}


  -- Howard.

On 25 August 2017 at 00:25, BJ Homer <bjhomer at gmail.com> wrote:

> 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:
>
>    1. The code is naturally parallel, in example dataResource and
>    imageResource are calculated in parallel.
>    2. The code handles errors and deadlocks by providing a default value
>    using `??`.
>    3. The code can be deadlock free or can help find deadlocks, see code
>    below, due to having a timeout and a means of cancelling.
>    4. 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/20170825/67d97b1b/attachment.html>