at:tutorial:actors
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
at:tutorial:actors [2007/04/07 17:24] – tvcutsem | at:tutorial:actors [2007/04/07 20:10] – tvcutsem | ||
---|---|---|---|
Line 89: | Line 89: | ||
==== Isolates ==== | ==== Isolates ==== | ||
- | The parameter passing semantics defined above rule out any possibility for an object to be passed by copy. The reason for this semantics is that objects encapsulate a lexical scope, and parameter passing an object by-copy would require the entire lexical scope to be parameter-[assed | + | The parameter passing semantics defined above rule out any possibility for an object to be passed by copy. The reason for this semantics is that objects encapsulate a lexical scope, and parameter passing an object by copy would require the entire lexical scope to be parameter-passed |
To enable objects to be passed by copy between actors, a special type of objects is introduced. These objects are called **isolates** because they are // | To enable objects to be passed by copy between actors, a special type of objects is introduced. These objects are called **isolates** because they are // | ||
Line 169: | Line 169: | ||
=== The Concept === | === The Concept === | ||
- | The most well-known language feature to reconcile return values with asynchronous message sends is the notion of a //future//. Futures are objects that represent return values that may not yet have been computed. Once the asynchronously invoked method has completed, the future is replaced with the actual return value, and objects that referred to the future transparently refer to the return value. | + | The most well-known language feature to reconcile return values with asynchronous message sends is the notion of a [[Wp> |
Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows: | Using futures, it is possible to re-implement the previous example of requesting our calculator actor to add two numbers as follows: | ||
Line 254: | Line 254: | ||
</ | </ | ||
- | The '' | + | The '' |
< | < | ||
Line 263: | Line 263: | ||
>> | >> | ||
</ | </ | ||
+ | |||
+ | Finally, it is useful to know that '' | ||
+ | |||
+ | < | ||
+ | def fut := when: calculator< | ||
+ | calculator< | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | When the future for ''< | ||
=== Futures and Striped Messages === | === Futures and Striped Messages === | ||
- | Explain: | + | As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking '' |
- | '' | + | |
- | '' | + | When a message send is striped with the '' |
+ | |||
+ | < | ||
+ | o<-m()@OneWayMessage | ||
+ | </ | ||
+ | |||
+ | When a message send is striped with the '' | ||
+ | |||
+ | < | ||
+ | o<-m()@FutureMessage | ||
+ | </ | ||
+ | |||
+ | Finally, it is possible to first invoke '' | ||
=== Conditional Synchronisation with Futures === | === Conditional Synchronisation with Futures === | ||
- | explain: explicit | + | Futures are useful to synchronise on the return value of an asynchronous message send. However, objects hosted by different actors may often want to synchronise based on other events or conditions. In such cases, |
+ | |||
+ | < | ||
+ | def [future, resolver] := makeFuture(); | ||
+ | consumer< | ||
+ | def val := /* calculate useful value */ | ||
+ | resolver.resolve(val); | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The resolver also defines a '' | ||
==== Actor Mirrors ==== | ==== Actor Mirrors ==== | ||
- | explain: mirror | + | An actor in AmbientTalk is primarily a //host// for regular objects. It is equipped with a message queue to receive asynchronous messages sent to one of its objects. The mirrors on these objects have corresponding meta-level operations such as '' |
+ | |||
+ | Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, | ||
+ | |||
+ | Overriding the actor' | ||
+ | |||
+ | < | ||
+ | def oldmirror := actor.install: | ||
+ | def send(msg) { | ||
+ | log(msg); | ||
+ | super^send(msg); | ||
+ | }; | ||
+ | }); | ||
+ | </ | ||
+ | |||
+ | Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent' | ||
+ | |||
+ | For a good use case of actor mirrors, see the '' | ||
+ | |||
+ | Other methods that can be overridden are '' | ||
==== Nesting Actors ==== | ==== Nesting Actors ==== | ||
lexical scoping rules for nested actors | lexical scoping rules for nested actors |
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag