Differences

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

--- at:tutorial:actors [2007/04/06 20:22] – added tvcutsem
+++ at:tutorial:actors [2007/04/07 17:18] – *changed tvcutsem
@@ Line 36: / Line 36: @@
 ==== 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]].
@@ Line 199: / Line 199: @@
 <note>Should add example here</note>
+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 ''=='' method. A word of warning though: equality on futures is defined as pointer equality, so a future will only be equal to itself. It does not compare the parameter object with its actual value, if it would be resolved.
 === 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:
+<code>
+def sum := calculator<-add(1,2);
+system.println(sum);
+>> <unresolved future>
+</code>
+AmbientTalk prints the future to the screen. At a later point in time, printing the future again may result in the following:
+<code>
+>system.println(sum);
+>> <resolved future:3>
+</code>
+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 ''sum''? In such cases, you need to register an observer with the future, which will be asynchronously notified when the actual value of the future has been computed.
+In AmbientTalk, this observer takes the form of a closure which will be applied asynchronously, taking as its only argument the actual value of the future. Registering the observer can be easily done by means of the ''when:becomes:'' function, exported by the futures module:
+<code>
+def sumFuture := calculator<-add(1,2);
+when: sumFuture becomes: { |sum|
+  system.println("The sum is " + sum);
+};
+</code>
+The first argument to ''when:becomes:'' is the future to observe. The second argument is a closure that takes the actual return value as a formal parameter. If there is a possibility that the asynchronously invoked method can raise an exception, this exception can be caught asynchronously by means of the ''when:becomes:catch:'' variant:
+<code>
+def sumFuture := calculator<-add(1,2);
+when: sumFuture becomes: { |sum|
+  system.println("The sum is " + sum);
+} catch: { |exc|
+  system.println("Exception: " + exc.message);
+};
+</code>
+Or, you can specify a stripe to only catch specific exceptions:
+<code>
+def divFuture := calculator<-divide(a,b);
+when: divFuture becomes: { |div|
+  system.println("The division is " + div);
+} catch: DivisionByZero using: { |exc|
+  system.println("Cannot divide "+a+" by zero!");
+};
+</code>
+The ''when:*'' functions are a very easy mechanism to synchronise on the value of a future without actually making an actor block: remember that all the ''when:becomes:'' function does is register the closure with the future. After that, the actor simply continues processing the statement following ''when:becomes:''. Also, even if the future is already resolved at the time the closure observer is registered, the closure is guaranteed to be applied asynchronously. This ensures that the code following a ''when:becomes:'' block is guaranteed to be executed before the registered closure itself:
+<code>
+when: sumFuture becomes: { |sum|
+  system.println("... and here later.");
+};
+system.print("Always here first");
+>>Always here first... and here later.
+</code>
+=== Futures and Striped Messages ===
+Explain:
+''o<-m()@FutureMessage''
+''o<-m()@OneWayMessage''
+=== Conditional Synchronisation with Futures ===
+explain: explicit futures using ''makeFuture''
 ==== Actor Mirrors ====