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
> <[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 -> 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
>> <[email protected] <mailto:[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
>> <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
