Python3pkg
diff --git a/‎pymodel/observation_queue.py‎
Lines changed: 8 additions & 1 deletion b/‎pymodel/observation_queue.py‎
Lines changed: 8 additions & 1 deletion
diff --git a/‎pymodel/pmt.py‎
Lines changed: 15 additions & 6 deletions b/‎pymodel/pmt.py‎
Lines changed: 15 additions & 6 deletions
diff --git a/‎samples/Socket/README.txt‎
Lines changed: 20 additions & 10 deletions b/‎samples/Socket/README.txt‎
Lines changed: 20 additions & 10 deletions
diff --git a/‎samples/Socket/fsmpy/socketFSM.py‎
Lines changed: 0 additions & 189 deletions b/‎samples/Socket/fsmpy/socketFSM.py‎
Lines changed: 0 additions & 189 deletions
diff --git a/‎samples/Socket/fsmpy/synchronous_graph.py‎
Lines changed: 0 additions & 38 deletions b/‎samples/Socket/fsmpy/synchronous_graph.py‎
Lines changed: 0 additions & 38 deletions
@@ -3,5 +3,12 @@
 """
 
 import collections
+import threading
 
-observation_queue = collections.deque() # initially empty
+# stepper sets asynch = True to make pmt wait for asynch observable actions
+asynch = False  # default: pmt doesn't wait for observable actions
+
+queue = collections.deque() # initially empty
+
+# initially clear, stepper sets when new item in queue, pmt clears when remove
+event = threading.Event() 
@@ -11,7 +11,7 @@
 import signal
 import traceback
 import TesterOptions
-from observation_queue import observation_queue
+import observation_queue as observation
 
 from ProductModelProgram import ProductModelProgram
 
@@ -63,8 +63,9 @@ def RunTest(options, mp, stepper, strategy, f, krun):
     # print 'Current state: %s' % mp.Current() # DEBUG
 
     # observable action
-    if observation_queue: # if queue not empty
-      (aname, args) = observation_queue.popleft()
+    if observation.queue: # if queue not empty
+      # print 'observable action branch, call observation.queue.popleft()'
+      (aname, args) = observation.queue.popleft()
       observable_action = True
       # print '< test runner gets', (aname, args)
       if not mp.ActionEnabled(aname, args):
@@ -83,9 +84,17 @@ def RunTest(options, mp, stepper, strategy, f, krun):
       (aname, args) = strategy.SelectAction(enabled)
       # exit conditions
       if not aname: 
-        if not cleanup:
-          infoMessage = 'no more actions enabled'
-        break   
+          if observation.asynch:
+            # print 'asynch branch, call observation.wait()' # DEBUG
+            observation.event.wait() # FIXME add timeout
+            # FIXME?  If another event occurs right now, we will miss it!
+            observation.event.clear() # got this event, prepare for next
+            continue # get observable action from queue
+          # if not asynch, come directly here
+          # if asynch, only reach here if event.wait() times out        
+          if not cleanup:
+              infoMessage = 'no more actions enabled'
+          break   
       elif cleanup and mp.Accepting():
         break
       else:
 
@@ -42,8 +42,8 @@ The sample includes these modules:
 - stepper, stepper_o, and stepper_a: three different steppers (also
   called test harnesses or adapters) that use the model program and
   scenarios to test actual sockets on localhost (via the Python
-  standard library socket module).  Also, Sender.py, Receiver.py,
-  etc.: other code for exercising the standard library socket module.
+  standard library socket module).  Also, stepper_util, code used
+  by all three steppers.
 
 - socket_simulator and socket_simulator_a: two simulators that can
   optionally replace the Python standard library socket module in the
@@ -343,7 +343,6 @@ synchronous msocket.  It is a graph of the msocket model program
 composed with the synchronous scenario machine, using the domains in
 the deterministic module.
 
-
 The stepper test harness
 
 The stepper module is a test harness (sometimes called an adapter)
@@ -394,6 +393,14 @@ discuss stepper_o and stepper_a, that support all model behaviors
 correctly.
 
 
+The stepper_util test harness utilities
+
+The stepper_util module defines constants and methods used by 
+all three steppers, including methods to open and close sockets
+and to make a connection.  The three stepper modules only
+handle the send and recv methods - that is their only difference.
+
+
 The test_stepper script
 
 The test_stepper module is a test script with three test cases that
@@ -582,22 +589,25 @@ invoke send_call and recv_call.
 
 The first test case does not use the synchronous scenario so it often
 blocks, times out, and fails.  The second test case uses the
-synchronous scenario so it never blocks and always succeeds.  With
-test_stepper, the second test case often fails, but here it always
+synchronous scenario so it never blocks and always succeeds.  With our
+test_stepper, the second test case often failed because the results
+were nondeterministically chosen by the model, but here it always
 succeeds because the return values are chosen by the implementation
 rather than the model, and the test outcomes are determined by
 checking those return values with the enabling conditions in the
 model.  The third case always succeeds for the same reason.  The third
 test case names the deterministic configuration, but it is not
-necessary because here the return values are chosen by the implemenation,
-not the model.
+necessary because here the return values are chosen by the
+implemenation, not the model.
 
 
 The stepper_a asynchronous stepper module
 
-The stepper_a module supports nondeterminism and asynchrony.  Each
-call to the implementation runs in its own thread, so it can wait
-without blocking the test run. ...
+The stepper_a module supports nondeterminism and asynchrony.  It is
+similar to stepper_o, but here each call to the implementation runs in
+its own thread, so the implementation can block at that call
+without blocking the whole test run.  This enables pmt to make another
+call that results in unblocking the earlier call.
 
 
 The socket_simulator module