Re: [platform-debug-dev] SUSPEND_RESUME event, Was: debug view features

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

platform-debug-dev-admin@xxxxxxxxxxx wrote on 10/25/2004 12:31:41 PM:

> 
> >>2. DebugEvent.SUSPEND_RESUME event.  In embedded debuggers especially
> >>retrieving and displaying data can be very expensive, especially when
> >>user is stepping and is only interested in seeing the IP move on the
> >>screen.  To address this, we would like to add a debug event that 
would
> >>only be intended for the debug view, in order to update the IP
> >>annotations.  I haven't fully thought through what other implications
> >>this might have so another method (rather than new event) of achieving
> >>the same ends might be more appropriate.
> >> 
> >>
> >
> >Events are intended to describe what is happening in the debug model, 
> >rather than be used directly as UI flags. Thus, I would prefer to see a 

> >different solution. Perhaps this means that the debug view should 
simply 
> >have a mode where it does not broadcast selection changes (which drives 

> >other views, such as the variables view)?
> > 
> >
> >
> In our case that actually is the model event: The model receives a 
> suspended event, but there is already a resume action queued.  So 
> currently, the model doesn't send out neither SUSPEND nor RESUME. 
> 
> IMO, the biggest problem with this suggestion is that after such event, 
> the state of the thread would still be running, and as such it shouldn't 

> return a stack frames, and the top stack frame would be needed by the 
> debug view in order to update the IP.  To avoid abusing the current 
> IThread interface too much, I think we'd need a new interface that 
> returns the last top stack frame, specifically for handling this 
> event... and I see why you wouldn't find that appealing.
> -Pawel
> 

OK, I don't quite understand the use case. The original comment says "... 
when the user is stepping and is only interested in seeing the IP 
move...". If the user has requested a step, why has the thread since 
resumed? Is this something specific to the debug architecture?

The debug view currently does *not* display source when a thread suspends 
but resumes before the debug view updates. I.e. when processing the 
suspend event the "LaunchViewEventHandler" does not process the suspend 
event if the thread responds "false" to "isSuspended()". This should mean 
you don't have to worry about coalecsing the suspend/resume events in your 
model.

Darin