Differences

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

--- at:tutorial:actors [2007/04/07 17:27] – tvcutsem
+++ at:tutorial:actors [2007/04/07 18:30] – tvcutsem
@@ Line 169: / Line 169: @@
 === 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>Future_(programming)|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.
 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: @@
 </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:
+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 guarantees that the code following a ''when:becomes:'' block is executed before the registered closure itself:
 <code>
@@ Line 263: / Line 263: @@
 >>Always here first... and here later.
 </code>
+Finally, it is useful to know that ''when:becomes:'' itself returns a future, who will be resolved with the value of applying the observer closure:
+<code>
+def fut := when: calculator<-add(1,2) becomes: { |sum|
+  calculator<-add(sum,3)
+};
+</code>
+When the future for ''<-add(1,2)'' becomes resolved with ''sum'', the ''fut'' future will be resolved with the future for the ''<-add(sum,3)'' message. When that message finally returns yet another sum, that sum will become the value of ''fut''.
 === Futures and Striped Messages ===
-Explain:
+As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking ''enableFutures(true)'' makes asynchronous sends return a future by default. Invoking ''enableFutures(false)'' returns ''nil'' by default. No matter how you enabled futures, you can always override the default setting by explicitly //annotating// the message send itself by means of two stripes exported by the futures module, as explained below.
-''o<-m()@FutureMessage''
-''o<-m()@OneWayMessage''
+When a message send is striped with the ''OneWayMessage'' stripe, it will never attach a future to the message. This is primarily useful if you have enabled futures by default, but want to send a one-way message requiring no result. In this case, simply send the message as follows:
+<code>
+o<-m()@OneWayMessage
+</code>
+When a message send is striped with the ''FutureMessage'' stripe, a future is attached to the message, but //only if futures have been enabled//! This is primarily useful if you have enabled futures, but not by default, because you don't want to incur the overhead of future-type message sends on each of the messages sent. In cases where futures become useful, simply send the message as follows:
+<code>
+o<-m()@FutureMessage
+</code>
+Finally, it is possible to first invoke ''enableFutures(false)'' and later enable it by default anyway by invoking ''enableFutures(true)''. However, once futures have been enabled by default, they can no longer be "turned off" by default. The reason for this is that if two separate files load the futures module and one enables futures by default and the other does not, then the net result is that they will be enabled by default, which will make both applications work correctly. If futures could be disabled, this can cause one object to unexpectedly make other objects crash because they depend on futures.
 === Conditional Synchronisation with Futures ===
-explain: explicit futures using ''makeFuture''
+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, futures can be created and resolved explicitly. The interface to the programmer is about the same as that specified by the E language:
+<code>
+def [future, resolver] := makeFuture();
+consumer<-give(future);
+def val := /* calculate useful value */
+resolver.resolve(val);
+</code>
+The ''makeFuture'' function exported by the futures module returns two values: a new, unresolved future, and an object called a //resolver// that can be used to resolve the future. As shown in the example, the future can be passed around as a regular object, and code can synchronise on the future by registering an observer on it, as shown previously. The resolver can be handed out separately to other parts of the program, which calculate the value for the future. This enables objects to "synchronise" on the future without being restricted to return values.
+The resolver also defines a ''ruin(e)'' method which can be used to explicitly ruin a future, causing any attached ''when:becomes:catch:'' blocks to trigger their ''catch:'' clause.
 ==== Actor Mirrors ====