seanhalle@4: 0x7ffff644ab60
seanhalle@4: 0x7ffff64487f0
seanhalle@4: 0x7ffff644b0a0
seanhalle@0: 
seanhalle@0: This test app has to exercise all the aspects of the request handling 
seanhalle@0: and the assigner code.
seanhalle@0: 
seanhalle@0: The assigner has two different Qs, plus a set of currentTaskSlvs  check for tasks and also check for explicit VPs.
seanhalle@0: 
seanhalle@0: So, in the app, make tasks, and also explicit VPs..  create such that they
seanhalle@0: interleave, cause assigner to switch between.
seanhalle@0: 
seanhalle@0: So, when start, make some tasks, then make some explicit VPs, then some
seanhalle@0: tasks, back and forth..  second batch of tasks have inter-dependencies, so
seanhalle@0: some of the VPs should jump into the middle of them..
seanhalle@0: 
seanhalle@0: Then, make it so that the last two tasks talk to each other, suspending
seanhalle@0: each other in turn, (which should cause the extra VPs to dissipate) and
seanhalle@0: after that they create a bunch more tasks.
seanhalle@0: 
seanhalle@0: Okay..  what needs to be exercised?
seanhalle@0: -] create new slave when task suspends
seanhalle@0: -] dissipate extra slave when have a task one, and no free tasks
seanhalle@0: -] suspend a task -> no tasks in taskQ -> empty task slave in slaveQ -> 
seanhalle@0:    dissipate that task slave -> explicit slave next in slaveQ, animate that.
seanhalle@0:   Means: To get an empty task slave in slaveQ -> create a task that will
seanhalle@0:    suspend, then create a normal task, which will cause an extra task 
seanhalle@0:    slave to be created
seanhalle@0: 
seanhalle@0: ===================
seanhalle@0: To have explicit VPs as well tasks.. add a field to semantic data holds type
seanhalle@0: of VP: whether it's for running tasks, vs an explicit VP.  when an
seanhalle@0: explicit dissipates, then switch it to a task VP that has no suspended
seanhalle@0: tasks..
seanhalle@0: 
seanhalle@0: So, in the semantic data, have:
seanhalle@0: -> taskVP vs explicitVP
seanhalle@0: -> has suspended task vs idle
seanhalle@0: 
seanhalle@0: Then fix the assigner logic:
seanhalle@0: When task suspends, get next readyVP, 
seanhalle@0:  check if it's an explicit
seanhalle@0:  and if yes, resume it,
seanhalle@0:  if no, then it's a taskVP, so get next task from taskQ and do it.
seanhalle@0:  Check whether taskQ empty
seanhalle@0:  if yes, then in the state: suspended taskVP, have empty taskVP, no tasks
seanhalle@0:    so, 
seanhalle@0: 
seanhalle@0: If taskQ empty, and VP Q empty, return NULL, which will trigger the
seanhalle@0:  back-to-back Master backoff.
seanhalle@0: 
seanhalle@0: If assigner called and no suspended slaves and taskQ empty..  does it have
seanhalle@0: a "current task slave"?  If not, create one in the semantic Env.
seanhalle@0: ==================================