Cancellation and time out can be built into futures, and async/await can interact with futures. I don’t think we need async/await itself to support either of those.
Just as a real-world example, C#’s async/await feature doesn’t have built-in timeout or cancellation support, but it’s still easy to handle both of those cases using the tools available. For example, one technique would be this (in C#): var cts = new CancellationTokenSource(); cts.CancelAfter(TimeSpan.FromMilliseconds(2500)); try { await DoAsync(cts.Token); } catch (OperationCanceledException) { // Handle cancelled } catch (Exception) { // Handle other failure } There are other techniques that would let you distinguish between cancellation and timeout as well. > On Aug 25, 2017, at 7:06 AM, Cavelle Benjamin via swift-evolution > <swift-evolution@swift.org> 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 -> Resource > func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image > func 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >> <https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782> >> >> -Chris >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution