I think we would be better off with a future type rather than async/await since they can offer timeout, cancel, and control over which thread execution occurs on.
-- Howard. On 26 August 2017 at 00:06, Cavelle Benjamin via swift-evolution < [email protected]> wrote: > Disclaimer: not an expert > > Question > I didn’t see any where the async is required to time out after a certain > time frame. I would think that we would want to specify both on the > function declaration side as a default and on the function call side as a > customization. That being said, the return time then becomes an optional > given the timeout and the calling code would need to unwrap. > > func loadWebResource(_ path: String) async -> Resourcefunc decodeImage(_ r1: > Resource, _ r2: Resource) async -> Imagefunc dewarpAndCleanupImage(_ i : > Image) async -> Image > func processImageData1() async -> Image { > let dataResource = await loadWebResource("dataprofile.txt") > let imageResource = await loadWebResource("imagedata.dat") > let imageTmp = await decodeImage(dataResource, imageResource) > let imageResult = await dewarpAndCleanupImage(imageTmp) > return imageResult > } > > > > So the prior code becomes… > > func loadWebResource(_ path: String) async(timeout: 1000) -> Resource?func > decodeImage(_ r1: Resource, _ r2: Resource) async -> Image?func > dewarpAndCleanupImage(_ i : Image) async -> Image? > func processImageData1() async -> Image? { > let dataResource = guard let await loadWebResource("dataprofile.txt”) > else { // handle timeout } > let imageResource = guard let await(timeout: 100) > loadWebResource("imagedata.dat”) else { // handle timeout } > let imageTmp = await decodeImage(dataResource, imageResource) > let imageResult = await dewarpAndCleanupImage(imageTmp) > return imageResult > } > > > > Given this structure, the return type of all async’s would be optionals > with now 3 return types?? > > .continuation // suspends and picks back up > .value // these are the values we are looking for > .none // took too long, so you get nothing. > > > > On 2017-Aug -17 (34), at 18:24, Chris Lattner via swift-evolution < > [email protected]> wrote: > > Hi all, > > As Ted mentioned in his email, it is great to finally kick off discussions > for what concurrency should look like in Swift. This will surely be an > epic multi-year journey, but it is more important to find the right design > than to get there fast. > > I’ve been advocating for a specific model involving async/await and actors > for many years now. Handwaving only goes so far, so some folks asked me to > write them down to make the discussion more helpful and concrete. While I > hope these ideas help push the discussion on concurrency forward, this > isn’t in any way meant to cut off other directions: in fact I hope it helps > give proponents of other designs a model to follow: a discussion giving > extensive rationale, combined with the long term story arc to show that the > features fit together. > > Anyway, here is the document, I hope it is useful, and I’d love to hear > comments and suggestions for improvement: > https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 > > -Chris > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
