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 revisionBoth sides next revision
at:tutorial:actors [2007/04/07 17:36] tvcutsemat:tutorial:actors [2007/04/07 18:06] – added tvcutsem
Line 254: Line 254:
 </code> </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> <code>
Line 266: Line 266:
 === Futures and Striped Messages === === 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>
  
 === Conditional Synchronisation with Futures === === Conditional Synchronisation with Futures ===
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag