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

[Howard Lovatt]

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 <
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 -> 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 <
> 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
>
>
>
> _______________________________________________
> 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/20170826/901f6a02/attachment.html>