Forward of blocked observer discussion

[Nurdin Premji <npremji at redhat dot com>]

The following is a pasted together transcript of whats going on with
blocked and Step/InstructionObservers.

Mark Wielaard wrote:
Implementing BlockObserver and StepObserver  

Andrew Cagney wrote:
> The two are being merged?  unblocking a block observer has the effect
of 
> a Step?

Mark
No, since I believe a BlockObserver (now called TaskObserver.Blocked) is
useful on its own. But the implementation will be almost identical since
I am merging the TaskState code paths that make sure a Task is
(temporarily) suspended since TaskObserver.Syscall and TaskObserver.Code
also need that (and currently use slightly different code to achieve
that functionality). This is the api doc that I wrote for it:

     /**
+     * Interface used to notify that a Task has been blocked for now.
+     * When the <code>updateBlocked</code> method is triggered it is
+     * guaranteed to Task has (temporarily) suspended
+     * execution. <code>updateBlocked</code> will be called at most
+     * once. If <code>Action.CONTINUE</code> is returned or after
+     * <code>requestUnblock()</code> is called on the Task the
+     * observer is removed from the task and will not be triggered
+     * unless it is explictily readded. To continiously monitor a
+     * running Task see the <code>Instruction</code> interface.
+     */
+    public interface Blocked
+       extends TaskObserver
+    {
+       /**
+        * The task has executed one instruction.  Return Action.BLOCK
+        * to block the task's further execution.
+        */
+       Action updateBlocked (Task task);
+    }

The TaskObserver.Instruction (which already existed, so I took that name
instead of StepObserver) does the same thing as Blocked, but stays
around. So if there are no other blocking observers it will put the Task
in Running state and almost immediately call updateExecuted(). Otherwise
it works the same as Blocked:

    /**
     * Interface used to notify that a Task has executed a single
     * instruction.
     */
    public interface Instruction
        extends TaskObserver
    {
        /**
         * The task has executed one instruction.  Return Action.BLOCK
         * to block the task's further execution.
         */
        Action updateExecuted (Task task);
    }


Andrew Cagney wrote:
> Mark, there's too much redundancy here - we should be after a
relatively 
> canonical set of control mechanisms - and redundancy means writing
twice 
> as much testing framework for what are effectively two mechanisms.  
> Having an observer remove itself when there's an unblock, is just 
> wierd.

Mark
Agreed, but if you control a Task through Observers only then there is
not much choice for 'temporarily holding a Task'. And I believe that
functionality on itself is useful.

>  Does that occure codintional on returning CONTINUE vs being sent 
> an unblock, ...., again too confusing for no value.

Yes. But if you think that is confusing we can just hold the task till
it is explicitly deleted.

> Sami, Adam, and I discussed this at length

Is that discussion documented somewhere?

>  and concluded just the blocking observer, where an unblock triggered
> an attempt at a single-step is all that was required.

So you only want the TaskObserver.Instruction? What about operations,
like getting the current stack frame for a stack trace or profile
sampling that don't need the extra complexity of stepping?