Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:tutorial:actors

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
at:tutorial:actors [2007/04/06 20:50] – tvcutsemat:tutorial:actors [2007/04/07 17:24] – tvcutsem
Line 36: Line 36:
 ==== Asynchronous Message Sending ==== ==== Asynchronous Message Sending ====
  
-AmbientTalk, like E, lexically distinguishes between synchronous method invocation and asynchronous message sending. The former is expressed as ''o.m()'' while the latter is expressed as ''o<-m()''. Regular object references can carry both kinds of invocations. Synchronous method invocation behaves as in any typical object-oriented language. When an asynchronous message is sent to a local object ("local" meaning "hosted by the same actor"), the message is enqueued in the actor's own message queue and the method invocation will be executed at a later point in time.+AmbientTalk, like E, syntactically distinguishes between synchronous method invocation and asynchronous message sending. The former is expressed as ''o.m()'' while the latter is expressed as ''o<-m()''. Regular object references can carry both kinds of invocations. Synchronous method invocation behaves as in any typical object-oriented language. When an asynchronous message is sent to a local object ("local" meaning "hosted by the same actor"), the message is enqueued in the actor's own message queue and the method invocation will be executed at a later point in time.
  
 Far references, like the reference stored in the variable ''a'' above, only carry asynchronous message sends, and as such totally decouple objects hosted by different actors in time: objects can //never// be blocked waiting for an outstanding remote procedure call, they can only communicate by means of purely //asynchronous// message passing. This is a key property of AmbientTalk's concurrency model, and it is a crucial property in the context of [[distribution|distributed programming]]. Far references, like the reference stored in the variable ''a'' above, only carry asynchronous message sends, and as such totally decouple objects hosted by different actors in time: objects can //never// be blocked waiting for an outstanding remote procedure call, they can only communicate by means of purely //asynchronous// message passing. This is a key property of AmbientTalk's concurrency model, and it is a crucial property in the context of [[distribution|distributed programming]].
Line 50: Line 50:
  
 But what happens when the method to invoke asynchronously has parameters that need to be passed. How does parameter passing work in the context of inter-actor message sending? The rules are simple enough: But what happens when the method to invoke asynchronously has parameters that need to be passed. How does parameter passing work in the context of inter-actor message sending? The rules are simple enough:
-  - Objects and closures are always passed **by reference**+  - Objects and closures are always passed **by far reference**
   - Native data types like numbers, text, tables, ... are always passed **by copy**   - Native data types like numbers, text, tables, ... are always passed **by copy**
  
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag