[Concurrency] Theoretical question about actors vs async

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.

Benjamin

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.

-Pierre

···

On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution <swift-evolution@swift.org> 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.

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), 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.

···

Le 18 sept. 2017 à 07:59, Pierre Habouzit <phabouzit@apple.com> a écrit :

On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution <swift-evolution@swift.org> wrote:

-Pierre

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

···

On Sep 18, 2017, at 2:32 AM, Benjamin Garrigues via swift-evolution <swift-evolution@swift.org> wrote:

Le 18 sept. 2017 à 07:59, Pierre Habouzit <phabouzit@apple.com <mailto:phabouzit@apple.com>> a écrit :

On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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), 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.

Thanks, i guess i didn't realize that async/await was in fact conceptually decoupled from the underlying task scheduling and execution mechanism, and that the gist really was in the state machine creation ( reading a bit more about c# implementation helped me understand it as well).

My question regarding async / await semantic on top of actors was also answered by the elixir Task api, which provides those functions as well, by spawning special child actors.
Which makes me think that maybe this api could be used as an inspiration for swift, so i'll just put the link here https://hexdocs.pm/elixir/Task.html just in case.

···

Le 18 sept. 2017 à 18:15, Pierre Habouzit <phabouzit@apple.com> a écrit :

On Sep 18, 2017, at 2:32 AM, Benjamin Garrigues via swift-evolution <swift-evolution@swift.org> wrote:

Le 18 sept. 2017 à 07:59, Pierre Habouzit <phabouzit@apple.com> a écrit :

On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution <swift-evolution@swift.org> 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), 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