[platform-debug-dev] [jdt-debug-dev] Collapsing thread behavior for leng

["Darin Wright/WPG/OTI" <Darin_Wright@xxxxxxx>]

I agree that collapsing stack frames is a presentation issue, and should be dealt with in the UI - not the model. I agree that we should change the IStep interface to be declared as non-blocking. I do not think that IStep (or any other model interface) requires a #timeout() method, as we want to keep all of the "collapse" behavior in the UI. Thus, if there is a timeout, the UI collapses the stack frames for that thread, and keeps a note that when retrieving children for that thread, there are none (i.e. do not query the model for stack frames until a "step-end" or "suspend" event has been received).

If Joe & Jed agree with this (and there are no other objections), I believe we can have Joe go ahead and make the neccessary changes.

Darin


----- Forwarded by Darin Wright/WPG/OTI on 11/11/2001 10:57 PM -----

Jed_Anderson@xxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 11/08/2001 06:19 PM

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-debug-dev] [jdt-debug-dev] Collapsing thread behavior for length operations

The overall problem that Joe describes is that our "collapse the stepping
thread that timed out" feature is being done in the model and not the UI.

I don't think we should update the model to achieve this goal, I think we
should do it all in the UI.  As I see this issue, collapsing threads that
have taken too long to step is analogous to the "*.class" filter in the
packages view.    It is a complex filter based off of elapsed time and
state in the model, but nonetheless it is a filter.  If we implement this
entirely in the UI, then _all_ debug models get this functionality for
free.  Otherwise other models have to implement it again.

The rough idea is the same as Joe's proposal:
     1. Step action requests that timers be started with the DebugUIPlugin
     2. Step action invokes the step
     3. If the timer finishes first, the DebugContentProvider collapses the
thread in the UI (not the model), otherwise the UI should update through
the "normal" way, and the DebugContentProvider just interrupts the Timer.

Details:
     * Creation of interface ITimerRequestListener (or other name... not
important now) with one method
          requestTimer(IStep step, long timeout)
     * DebugUIPlugin needs to maintain a list of ITimerRequestListeners
     * DebugUIPlugin#fireRequestTimer(IStep step, long timeout) needs to be
created and implemented to notify the listeners with a requestTimer(IStep,
long) call.
     * DebugContentProvider needs to register as a ITimerRequestListener
with the DebugUIPlugin, it currently registers as an ILaunchListener and an
IDebugEventListener, so this shouldn't be an issue.
     * DebugContentProvider implements requestTimer(IStep step, long
timeout) to do the following
          * store step
          * start a timer for timeout
          * check incoming suspend events and check to see if they are step
end events.  if they are compare the stack frame against the stored step.
if they match stop the timer and continue like normal
          * if timer expires filter the view so that only the thread shows
          * NOTE: this is a simplification to make explanation easier, you
have to keep a map of IStep objects to Timer objects

This gives Joe the same functionality so that he can programmatically
invoke the toString without getting the collapsing of the Thread, but it
also cleans up the code UI-Model relationship so that other clients of the
model will not be disrupted by the collapsing feature.

Issue #1:
Since all of the "request for timer" functionality is on the DebugUIPlugin
in my proposal, any other clients of the debug model that are interested in
timeouts can implement them.

Issue #2:
I suggest we do away with the ability for model implementers to write
blocking step methods.  If we require that they are non-blocking, and some
model can only do blocking, then it is their responsibility to wrap their
step actions in Threads.  It is the difference between adding API (new
method/interface) and changing API (remove comments that indicate that we
support blocking).  I support the change proposal because I think the
interface is unneeded (read: code bloat) and I don't think forcing model
implementers to provide non-blocking implementations is unreasonable.

jkca

----- Forwarded by Jed Anderson/MIN/OTI on 11/08/2001 05:11 PM -----
                                                                                                                    
                    Joe_Szurszewski@oti.c                                                                           
                    om                           To:     jdt-debug-dev@xxxxxxxxxxx, platform-debug-dev@xxxxxxxxxxx  
                    Sent by:                     cc:                                                                
                    jdt-debug-dev-admin@e        Subject:     [jdt-debug-dev] Collapsing thread behavior for length 
                    clipse.org                   operations                                                         
                                                                                                                    
                                                                                                                    
                    11/08/2001 04:27 PM                                                                             
                                                                                                                    
                                                                                                                    




        In the latest build (20011107), there is a problem using the
'details pane' in the VariablesView.
If an evaluation of 'toString()' takes longer than the established timeout
value for evaluations (currently
3 seconds), the stack frames of the suspended thread are collapsed
(disappear) to indicate that something
lengthy is happening.  This causes a CHANGE DebugEvent to be fired, which
is ultimately heard by the VariablesView,
which resets its input, which blanks out both it and the details pane.  The
view stays blank until the
evaluation finishes, at which time the SUSPEND event causes the
VariablesView to be repopulated, although nothing
in the view is expanded, and the previous selection is lost.  The logic for
handling the 'collpase timer'
currently resides in JDIThread, so that ALL method invocations on a thread
get this behavior  This seems counterintuitive,
since JDIThread is part of the model, not the UI.  I propose moving this
logic into the UI as follows:
        -        Move timeout monitoring to the Action subclasses that need
collapse behavior
                (ex. StepIntoActionDelegate)
        -        On action invocation, the action registers for DebugEvents

        -        Action starts timer (copy std. Timer class &
ITimeoutListener interface)
        -        Action invokes the appropriate method (ex. stepInto) on
the IStep debug element in question
        -        Action waits for appropriate DebugEvent (STEP_END on debug
element in question) or timeout,
                whichever comes first
        -        If timeout happens first, invoke some sort of "timeout()"
method on the IStep debug element.
                This cleans up the internal model state of the debug
element, and fires a CHANGE DebugEvent
                so the UI (e.g., DebugView) can update
        -        If STEP_END callback happens first (on the element in
question), cancel the timer.
                The DebugView will also hear this event and update the UI
accordingly

Making this work requires several things.  (1) New API on IStep (or a new
superinterface that IStep extends)
that defines the "timeout()" method.  There is probably a better name for
this.  (2) Changes to JDIThread &
appropriate action classes to relocate timing logic.  (3) Access to Timer &
ITimeoutListener types.

Unresolved issues with this approach: (1) Do any other capability
interfaces beyond IStep (ex. ISuspendResume)
need a "timeout()" method?  (2) Current JDI stepping implementation is
non-blocking.  IStep JavaDoc says
stepping implementations may be either blocking or non-blocking.  Do we
intend to stick with this?  If so,
we might need extra logic in the actions to handle blocking
implementations, so that they don't block the
UI thread.  If this is the case, we would also need a method on IStep (or
its superinterface) along the
lines of "isBlocking()" so that an IStep implementation can report whether
it uses a blocking implementation
of stepping, and thus actions can behave correctly.

Benefits: (1) Collapse behavior is now under UI control.  Collapsing only
happens through user-initiated events that
ask for it.  Programmatic evaluation, such as the evaluation of the
toString() method for the details pane, no longer gets
the collapse behavior whether it wants it or not.  (2) Cleaner model/UI
separation.

Any thoughts?


_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev