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 <bjho...@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@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@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