> On Sep 18, 2017, at 2:32 AM, Benjamin Garrigues via swift-evolution > <[email protected]> wrote: > > > > Le 18 sept. 2017 à 07:59, Pierre Habouzit <[email protected] > <mailto:[email protected]>> a écrit : > >>> On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> I've read Chris Lattner proposal on concurrency, and if i'm correct, the >>> proposal is to start implementing async / await mechanism first, then other >>> more evolved mechanisms (such as actors) on top later. >>> >>> My question after reading the many conversations (and confusion) around the >>> execution order of async / await on the mailing list is this : >>> Isn't the actor model a more "elementary" concurrency model than async / >>> await, and so, from a theoretical point of view, wouldn't it make more >>> sense to implement it first as a layer to build future other concurrency >>> mechanisms on top ? >>> >>> I'm putting emphasis on the "theoretical" aspect of my question, because >>> i'm 100% certain that if Mr Lattner decided to go this path, it's because >>> it makes more sense from an implementation point of view. >> >> Actors is a way higher level construct than async/await. >> >> async/await is IMO an interesting low level construct that explains to the >> language where your execution flow requires to be broken in two (what is >> syntactically before and after the "await") to wait for some event before >> the second half can be done. >> >> Unlike Actors, it doesn't try to explain what/how/... this is done, which >> makes it lower level. > > That's also how i first thought about it, but the more i digg the subject ( > especially after viewing https://youtu.be/7erJ1DV_Tlo > <https://youtu.be/7erJ1DV_Tlo>), the more i understand actors as a > fundamental unit of computation (addressable, with a state), and not a whole > framework. > > all the questions i see raised with async/await ( queue hoping, timeouts, > error handling, ressource allocation, etc) simply aren't there with actors, > because imho, the model is conceptually simpler ( and thus a saner basis for > building concurrency). > > I started thinking about what, in the "everything's an actor" model, > async/await would mean if called from within an actor and it seems like it > would mean that once the await call is made, all the messages sent to that > actor are blocked until the response from that call is received ( which is > dangerous if the message comes from the network, but not that much when > running in the same computer). That seemed interesting but i stopped there > because i wanted to have the opinion of more qualified people first.
All of this is orthogonal. async/await, is about explaining to the compiler how to split sequential synchronous looking code into an asynchronous state machine. Unlike actors that attach rules and semantics to this, async/await is really just about the compiler transform (which is *not* that easy, especially when C stacks happen in the mix). -Pierre
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
