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

[Andrew Cagney <cagney@redhat.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 
:-( :-)