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

[Andre]

2017/08/19 3:51、Chris Lattner <clattner at nondot.org>のメール:

>> On Aug 17, 2017, at 10:50 PM, Andre <pyunpyun at me.com> wrote:
>> 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… :/
> 
> Something like this could definitely be built and added later: the sketch for async/await is intentionally kept as minimal as possible.  That said, this seems like it is wandering into territory that would make sense to be API, rather than first class language feature.
I see, yea, the only reason I brought it up is because it jumped out as an important concept in my mind that a lot of times seems to get neglected when people write async operations (e.g “how long am I willing to wait for this to finish”.... there are a lot of times I have to force quit apps that’s freeze or become non-responsive, and it’s almost alway waiting to acquire some resource) so i just felt it would be good to have upfront support in some manner for timeouts...

>> 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?
> 
> Yes, I completely agree and know what you’re talking about here.  You’re unintentionally poking one of my other axes the grind.  :)
Wow great! ^^

> This desire (to have conceptual “states” that a type moves through) is something that is super common.  Files can be in “initialized” and “open” states, and that changes the valid actions that can be performed on them.  A mutex can be locked or unlocked etc.  Being able to express these invariants is highly related to pre and post conditions.
> 
> One abstraction that has been developed in the industry is the notion of typestate (https://en.wikipedia.org/wiki/Typestate_analysis), which underlies common abstractions in static analyzer tools like the Clang Static Analyzer.  I would love to see these ideas developed and built out at some point in time, and perhaps the next time I get a long block of time I’ll write another manifesto on those ideas ;-)
I would very very much look forwards to that manifesto and would love to help out in any way in supporting such a concept!

> Coming back to your point, these ideas apply just as much to structs and classes as they do actors, so I think it should be a feature orthogonal to actors.
Definitely true, that. 

―

If this was to be a feature at some point, when do you foresee a possible inclusion for it?
Swift 5,or 6 timeframe?

Meanwhile I will go and start playing with the languages (plaid etc) in the typestate theory wiki link you just shared! I’m glad there is a formal theory behind this, very cool.

Andre

iPadから送信

> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170819/a7cf1533/attachment.html>