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:36] – tvcutsem | at:tutorial:actors [2007/04/24 21:02] – added tvcutsem | ||
---|---|---|---|
Line 33: | Line 33: | ||
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 disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below. | 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 disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below. | ||
+ | |||
+ | Note that, if the object referred to by a far reference is striped with one or more stripes, the far reference itself is striped with the same stripes. Hence, an object located on a remote actor can be tested for its stripes // | ||
==== Asynchronous Message Sending ==== | ==== Asynchronous Message Sending ==== | ||
Line 254: | Line 256: | ||
</ | </ | ||
- | The '' | + | The '' |
< | < | ||
Line 263: | Line 265: | ||
>> | >> | ||
</ | </ | ||
+ | |||
+ | 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 | + | In AmbientTalk, |
+ | |||
+ | < | ||
+ | def outer := actor: { | ||
+ | def x := 1; | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | |||
+ | def inner := actor: { | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | If both the '' | ||
+ | |||
+ | Recall that isolates could be given selective access to their enclosing lexical scope by specifying accessed variables as formal parameters to their initializing closure, which gave rise to copying the variable into the isolate. We allow actors to do the same. Hence, the above example can be written properly as: | ||
+ | |||
+ | < | ||
+ | def outer := actor: { | ||
+ | def x := 1; | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | |||
+ | def inner := actor: { |x| | ||
+ | def get() { x }; | ||
+ | def set(v) { x := v }; | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | It still makes sense to nest actors, but each actor will have its own local copy of lexically shared variables. Furthermore, |
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag