frysk.rt.SteppingEngine poking at a task's blocker list?

[Andrew Cagney <cagney at redhat dot com>]

Tim, Mike,

I noticed this in frysk.rt.SteppingEngine:

  /**
    * Unblock a task so that, from the point of view of the stepping
    * engine, execution can continue. For now this unblocks
    * instruction observers and code observers for breakpoints, but
    * ultimately I (timoore) think it should unblock all blockers.
    */
   public boolean continueForStepping(Task task, boolean unblockStepper) {
       if (unblockStepper) {
           task.requestUnblock(this.steppingObserver);
       }
       TaskObserver[] blockers = (TaskObserver 
[])task.getBlockers().clone();
       for (int j = 0; j < blockers.length; j++) {
           // One of ours?
           if (blockers[j] instanceof Breakpoint) {
               task.requestUnblock(blockers[j]);
           } else {
               // Some blocker that we don't know about
               // System.out.println("Unknown blocker " + 
blockers[j].toString());
               // return false;
           }
       }
       return true;
   }

I'm not sure what is happening here, but the underlying code should 
operate as:
-> process hits a breakpoint instruction
-> all low-level CodeObservers fire
-> all corresponding high-level Breakpoint observers fire
-> Breakpoint observers each notify Stepping engine to stop (accompanied 
by corresponding low-level CodeObserver doing the block)
This will leave the SteppingEngine with a full list of CodeObservers to 
unblock without needing to poke around an assumed live task's internal 
state.

The flexibility of this approach also lets us write custom high-level 
breakpoint observers, in the monitor say, that can be implemented using 
just the Breakpoint and its shared-library Manager, and not have to 
worry about the stepping engine at all.

Andrew

PS: And it prevents me moving this blockers stuff into frysk.proc.live 
:-( :-)