User Tools

Site Tools


at:tutorial:actors

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
at:tutorial:actors [2007/04/07 18:06] – added tvcutsemat:tutorial:actors [2007/04/07 18:30] tvcutsem
Line 263: Line 263:
 >>Always here first... and here later. >>Always here first... and here later.
 </code> </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 === === Futures and Striped Messages ===
Line 279: Line 289:
 o<-m()@FutureMessage o<-m()@FutureMessage
 </code> </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 === === 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 ==== ==== Actor Mirrors ====
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag