Differences

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

--- at:tutorial:actors [2008/11/04 10:16] – added tvcutsem
+++ at:tutorial:actors [2009/09/30 13:31] – added tvcutsem
@@ Line 182: / Line 182: @@
 ==== The Concept ====
-The most well-known language feature in concurrent and distributed languages (for example, in ABCL, the actor-based concurrent language) to reconcile return values with asynchronous message sends is the notion of a  [[Wp>Future_(programming)|future]]. Futures are also commonly known by the name of //promises// (this is how they are called in the [[http://www.erights.org|E language]] and in Argus). 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 in concurrent and distributed languages (for example, in ABCL, the actor-based concurrent language) to reconcile return values with asynchronous message sends is the notion of a  [[Wp>Future_(programming)|future]]. Futures are also commonly known by the name of //promises// (this is how they are called in the [[http://www.erights.org|E language]] and in Argus). Wikipedia has [[Wp>Futures_and_promises|an excellent article]] about promises, futures and their differences.
+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 317: / Line 319: @@
 o<-m()@FutureMessage
 </code>
+When a message send is annotated with the ''Due'' type tag, the attached future is expected to be resolved before a specified deadline. As shown below, the annotation takes as parameter a timeout value (in milliseconds) relative to the time at which a message is sent. The future is automatically ruined with a ''TimeoutException'' if the timeout elapses before the return value was received. This is primarily useful to have time-based delivery policy guarantees on asynchronous messages.
+<code>
+o<-m()@Due(timeout);
+</code>
+<note>
+More details about the ''Due'' annotation can be found in the section about [[distribution#dealing_with_permanent_failures|leased object references]] in the chapter on distributed programming.
+</note>
 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.