[swift-evolution] [Concurrency] async/await + actors

[Adam Kemp]

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 at 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 at swift.org <mailto:swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/dcb8d3c6/attachment.html>