Differences

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

--- at:tutorial:actors [2009/01/29 16:44] – elisag
+++ at:tutorial:actors [2009/01/29 16:48] – elisag
@@ Line 318: / Line 318: @@
 </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.
+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>
@@ Line 325: / Line 325: @@
 <note>
-More details about ''Due'' annotation can be found in the chapter about [[distribution#dealing_with_permanent_failures|leased object references]].
+More details about the ''Due'' annotation can be found in the section about [[distribution#dealing_with_permanent_failures|leased object references]] within the chapter about distributed programming.
-<note>
+</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.