Differences

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

--- at:tutorial:actors [2007/07/18 09:12] – Adding elisag
+++ at:tutorial:actors [2007/07/18 09:29] – elisag
@@ Line 1: / Line 1: @@
-<note>This tutorial is under heavy construction!</note>
 ====== Concurrent Programming with Actors ======
@@ Line 32: / Line 31: @@
 As you can see, actors are created similar to objects. The ''actor:'' method, defined in the global lexical scope, takes a closure as its sole argument and uses that closure to initialize the behaviour of the new actor. The creator of the actor immediately receives a so-called //far reference// to this behaviour object, and from that moment on the creating actor and the created actor run in parallel, each capable of processing incoming messages autonomously.
-So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references only allow asynchronous access to the referenced object. This is enforced by the kind of messages that these references can carry, as will be further explained in the next section.
+So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references only allow asynchronous access to the referenced object. This is enforced by the kind of messages that these references can carry, as will be explained in the next section.
 <note>
@@ Line 38: / Line 37: @@
 </note>
-The figure below summarizes AmbientTalk's concurrency model where actors are represented as communicating event loops. The dotted lines represent the event loop threads of the actors which perpetually take messages from their message queue and synchronously execute the corresponding methods on the actor's owned objects. An event loop thread never ``escapes'' its actor boundary. When communication with an object in another actor is required, a message is sent asynchronously via a far reference to the object. For example, as shown in the figure, when A sends a message to B, the message is enqueued in the message queue of B's actor which eventually processes it.
+The figure below summarizes AmbientTalk's concurrency model where actors are represented as communicating event loops. The dotted lines represent the event loop threads of the actors which perpetually take messages from their message queue and synchronously execute the corresponding methods on the actor's owned objects. An event loop thread never //escapes// its actor boundary. When communication with an object in another actor is required, a message is sent asynchronously via a far reference to the object. For example, as shown in the figure, when A sends a message to B, the message is enqueued in the message queue of B's actor which eventually processes it.
-{{:at:tutorial:concurrencymodel.png?450|:at:tutorial:concurrencymodel.png}}
+{{ :at:tutorial:concurrencymodel.png?450 |AmbientTalk actors as communicating event loops }}
 ===== Asynchronous Message Sending =====