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