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

[Cavelle Benjamin]

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> 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
> 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/8271a5cc/attachment.html>