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

[Andre]

Hi Chris, 

This looks amazing(!) … I am really looking forward to the end result whatever that may be, because I know it will be awesome.
Im really excited and a lot raced though my mind while I read it...

———————————————
Part 1: Async/await

    let dataResource  = await loadWebResource("dataprofile.txt")


Was there any thought about introducing the concept of a timeout when awaiting?

Something like an `await for:` optional parameter?
Then, if used with try, it could go like…

    let dataResource  = try await for:10/*seconds*/ loadWebResource("dataprofile.txt”) catch _ as Timeout { //abort,retry cancel } 

Timeouts should probably be handled at a higher level, but its just something that jumped out to me a little, since its something I notice sometimes people neglect to take care of… :/


———————————————
Part 2: Actors

One other thing that also jumped at me was, if we are going to have actors, and having them encapsulate/isolate state, would it also make sense to make sure that we can’t invoke state changing messages when its invalid?

As an example, if we had a ”downloader” actor that downloads multiple files, we wouldn't want to be able to send invalid messages such as `begin` when downloading has already ”begun”…. Would it then make more sense to have callable messages be determined by the publicly visible state of the actor instead?

For example, if the downloader actor hasn’t begin downloading, then the only available messages are `begin` and `addItem`, conversely if the actor is ”downloading” then the only messages it should accept are `cancel` and `getProgress`…

Im thinking something along the lines of merging a class with an enum I suppose… 
Just put a gist here if you want to see what I am thinking: https://gist.github.com/andrekandore/f2539a74002d1255cfc3da58faf0f007

It may add complexity but I think (at least for me) instead of writing a lot of boilerplate, it would come naturally from the "state contract"… and it could be more safe than manually doing it myself….

Anyways, maybe Im wrong, but just something I thought about…

———————————————

I would appreciate to hear what you think. ^_^

Cheers,

Andre



> H29/08/18 7:25、Chris Lattner via swift-evolution <swift-evolution at swift.org>のメール:
> 
> 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/20170818/9775760c/attachment.html>