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/06 20:22] – added tvcutsem | at:tutorial:actors [2007/04/07 17:36] – tvcutsem | ||
---|---|---|---|
Line 36: | Line 36: | ||
==== Asynchronous Message Sending ==== | ==== Asynchronous Message Sending ==== | ||
- | AmbientTalk, | + | AmbientTalk, |
Far references, like the reference stored in the variable '' | Far references, like the reference stored in the variable '' | ||
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** | ||
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 199: | Line 199: | ||
< | < | ||
+ | |||
+ | When a future eventually becomes resolved with a value, any messages that were accumulated by the future are forwarded asynchronously to the actual return value, such that it appears as if the original object had sent the messages to the actual return value in the first place. | ||
+ | |||
+ | AmbientTalk only allows one method to be synchronously invoked on a future, the '' | ||
=== Working with Resolved Futures === | === Working with Resolved Futures === | ||
+ | As explained above, it is always correct to use asynchronous message sends to communicate with a future. Sometimes, however, we may want to perform some operation on the return value other than message sending, for example, printing it to the screen. If you print the future directly, you get the following: | ||
+ | |||
+ | < | ||
+ | def sum := calculator< | ||
+ | system.println(sum); | ||
+ | >> < | ||
+ | </ | ||
+ | |||
+ | AmbientTalk prints the future to the screen. At a later point in time, printing the future again may result in the following: | ||
+ | |||
+ | < | ||
+ | > | ||
+ | >> < | ||
+ | </ | ||
+ | |||
+ | This time, the future was printed when the return value was computed. But what if we simply want to inform the user of the actual value of '' | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | < | ||
+ | def sumFuture := calculator< | ||
+ | when: sumFuture becomes: { |sum| | ||
+ | system.println(" | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The first argument to '' | ||
+ | |||
+ | < | ||
+ | def sumFuture := calculator< | ||
+ | when: sumFuture becomes: { |sum| | ||
+ | system.println(" | ||
+ | } catch: { |exc| | ||
+ | system.println(" | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | Or, you can specify a stripe to only catch specific exceptions: | ||
+ | |||
+ | < | ||
+ | def divFuture := calculator< | ||
+ | when: divFuture becomes: { |div| | ||
+ | system.println(" | ||
+ | } catch: DivisionByZero using: { |exc| | ||
+ | system.println(" | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | < | ||
+ | when: sumFuture becomes: { |sum| | ||
+ | system.println(" | ||
+ | }; | ||
+ | system.print(" | ||
+ | >> | ||
+ | </ | ||
+ | |||
+ | === Futures and Striped Messages === | ||
+ | |||
+ | Explain: | ||
+ | '' | ||
+ | '' | ||
+ | |||
+ | === Conditional Synchronisation with Futures === | ||
+ | explain: explicit futures using '' | ||
==== Actor Mirrors ==== | ==== Actor Mirrors ==== |
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag