/interpreter/tags/reactive-pattern-matching/src/edu/vub/at/signals/SignalListener.java

  1/**
  2 * AmbientTalk/2 Project
  3 * SignalListener.java created on Jun 29, 2008 at 11:39:06 AM
  4 * (c) Programming Technology Lab, 2006 - 2007
  5 * Authors: Tom Van Cutsem & Stijn Mostinckx
  6 * 
  7 * Permission is hereby granted, free of charge, to any person
  8 * obtaining a copy of this software and associated documentation
  9 * files (the "Software"), to deal in the Software without
 10 * restriction, including without limitation the rights to use,
 11 * copy, modify, merge, publish, distribute, sublicense, and/or
 12 * sell copies of the Software, and to permit persons to whom the
 13 * Software is furnished to do so, subject to the following
 14 * conditions:
 15 *
 16 * The above copyright notice and this permission notice shall be
 17 * included in all copies or substantial portions of the Software.
 18 *
 19 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 20 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 21 * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 22 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 23 * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 24 * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 25 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 26 * OTHER DEALINGS IN THE SOFTWARE.
 27 */
 28package edu.vub.at.signals;
 29
 30import java.util.EventListener;
 31
 32import edu.vub.at.objects.ATMessage;
 33
 34/**
 35 * SignalListener is an interface specifying which messages can be sent to any dependent
 36 * reactive computation. This interface provides methods to get the dependency height of
 37 * a dependent computation and update it if necessary.
 38 * 
 39 * It also provides methods to unhook signal listeners,  such that obsolete branches can
 40 * be removed from the dataflow graph.
 41 * 
 42 * @author smostinc
 43 *
 44 */
 45public interface SignalListener extends EventListener {
 46
 47	/**
 48	 * This method is called when one of the parent signal has been updated.  The update
 49	 * is not performed immediately when this method is invoked. There are two important
 50	 * reasons for delaying the update:  First of all,  the parent signal may not belong
 51	 * to the same event loop as its child. This is typically the case when modelling an
 52	 * external event source such as time, key strokes, etc.  In this case, the external
 53	 * process should not be able to perform computation inside another event loop.
 54	 * <p>
 55	 * Even if parent and child signal belong to the same event loop, performing updates
 56	 * of the child signal immediately after having updated the parent is not acceptable
 57	 * since this may introduce update glitches. Consider the following example:
 58	 * <pre><code>
 59	 * (seconds < (seconds + 1))
 60	 * </code></pre>
 61	 * In the above example, both the comparison <code>&lt;</code> and the addition have
 62	 * a direct dependency on the seconds signal.  If dependent signals were immediately
 63	 * updated, the comparison could be updated first, yielding <code>false</code>.
 64	 * <p>
 65	 * To avoid update glitches updates are not performed immediately, but are scheduled
 66	 * to be performed when the dataflow engine reached the proper dependency height. As
 67	 * such, update glitches can be avoided, since the dependency height of   <code>&lt;
 68	 * </code> in the example is 2 since it depends on <code>seconds</code>  (height: 0) 
 69	 * and <code>seconds + 1</code> (height: 1). 
 70	 * 
 71	 * @param theParent the parent signal that has been updated
 72	 * @param theUpdate the update that was propagated by that parent
 73	 */
 74	public void scheduleUpdate(ATSignal theParent, ATMessage theUpdate);
 75
 76	/**
 77	 * 
 78	 * @param theParent
 79	 * @param theUpdate
 80	 * @return whether the listener wants to receive subsequent updates
 81	 */
 82	public boolean performUpdate(ATSignal theParent, ATMessage theUpdate);
 83	
 84	/**
 85	 * Every signal is assigned a dependency height,  which determines the stratus where
 86	 * the signal is situated in the dataflow graph. Updates are propagated first to the
 87	 * signals with the lowest dependency height to ensure that signals are only updated
 88	 * when the signals they depend on are guaranteed not to contain stale information.
 89	 * 
 90	 * @return The dependency height of this signal listener.
 91	 */
 92	public int dependencyHeight();
 93	
 94	/**
 95	 * When the value of a behavior is set to another behavior, this behavior may have a
 96	 * higher dependency height. Updates from the newly assigned value should henceforth
 97	 * be propagated to all dependent computations.  However, before these update can be
 98	 * propagated the dependency graph should be stratified anew.  There are essentially
 99	 * two solutions: we can keep the strata static and establish a "delayed" dependency
100	 * between both behaviors, which implies that updates are only propagated during the
101	 * next turn. The alternative is to reassign the dependency heights of all dependent
102	 * signals, such that they are strictly greater than those of the new parent signal.
103	 * <p>
104	 * The latter approach is adopted in <b>FrTime</b>, as well as in AmbientTalk.  This
105	 * method is used to update the dependency height of a signal listener.  It verifies
106	 * whether the new height is strictly greater than its current dependency height and
107	 * transitively updates dependent signals if necessary.
108	 */
109	public void updateDependencyHeight(int newDependencyHeight);
110	
111	/**
112	 * When constructing parts of the dataflow network inside a method which was invoked
113	 * with a signal as receiver or parameter,  the constructed dataflow will implicitly
114	 * depend on the signals that were passed to the method as well.  When these signals
115	 * change, the method will be executed anew, and the dataflow network that was built
116	 * during the previous invocation is no longer valid.
117	 * <p>
118	 * This observation is a generalization of the technique in <b>FrTime</b>, where the
119	 * problem only surfaces when using signals in conditions or in function position.
120	 * <p>
121	 * The unhook method is used to deconstruct the dataflow graph, whenever a signal on
122	 * which the signal listener depended implicitly is changed. The signal listener has
123	 * to ensure that updates will no longer be propagated to rule out already scheduled
124	 * update attempts.  
125	 */
126	public void unhook();
127}