Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 323826 - Need a way to control the half second delay in SteppingControler
Summary: Need a way to control the half second delay in SteppingControler
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf (show other bugs)
Version: 7.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 7.0.2   Edit
Assignee: Anton Leherbauer CLA
QA Contact: Pawel Piech CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-27 10:11 EDT by Dobrin Alexiev CLA
Modified: 2010-09-28 07:08 EDT (History)
2 users (show)

See Also:


Attachments
Patch for review (3.45 KB, patch)
2010-08-31 03:56 EDT, Anton Leherbauer CLA
aleherb+eclipse: iplog-
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dobrin Alexiev CLA 2010-08-27 10:11:56 EDT
Build Identifier: 

I like the feature of Eclipse and DSF that if the user steps while debugging the debug view doesn’t update for half a second with an anticipation that the target will be suspended again. 

The problem is that under some conditions (slow connection to the target) stepping takes around a second and the debug view flickers badly. 

I noticed that half second is a hard coded delay in DSF’s class SteppingController. 

Is it possible for a DSF debuggers to be able to customize the stepping controller somehow?

One way is to let the user customize that with a preference option. 
Another way is for the Stepping Controller to be customizable from the DSF debugger. 
A third way is the Stepping Controller to gather some kind of stepping statistics and automatically readjust the delay within a reasonable interval based on date collected. 




Reproducible: Always

Steps to Reproduce:
NA
Comment 1 Anton Leherbauer CLA 2010-08-30 10:21:19 EDT
In our debugger we handle this case by providing cached frame information as long as a step is in progress, instead of returning an error because the target is running.  This avoids the flicker (collapsing of the thread node).
But, it's also no problem to make the delay customizable for debugger implementations.  A simple setStepTimeout(int) should do, I suppose?
Comment 2 Dobrin Alexiev CLA 2010-08-30 11:04:10 EDT
(In reply to comment #1)
> In our debugger we handle this case by providing cached frame information as
> long as a step is in progress, instead of returning an error because the target
> is running.  This avoids the flicker (collapsing of the thread node).
> But, it's also no problem to make the delay customizable for debugger
> implementations.  A simple setStepTimeout(int) should do, I suppose?

Adding public setStepTimeout(int) to the class SteppingController will work for me. 
May be it should be pared with getStepTimeout for completeness.
Comment 3 Anton Leherbauer CLA 2010-08-31 03:56:54 EDT
Created attachment 177814 [details]
Patch for review

This is what I intend to commit.  Please review.
Comment 4 Dobrin Alexiev CLA 2010-08-31 09:50:27 EDT
The proposed change satisfies my request.
Thanks you.
Comment 5 Anton Leherbauer CLA 2010-08-31 10:02:10 EDT
Committed to HEAD.
Comment 6 Dobrin Alexiev CLA 2010-08-31 11:40:19 EDT
The proposed change satisfies my request.
Thanks you.
Comment 7 Dobrin Alexiev CLA 2010-09-17 14:13:40 EDT
Tony, can we have this change in CDT 7.0.x as well?
Comment 8 Anton Leherbauer CLA 2010-09-22 09:09:26 EDT
SteppingController is provisional API, so I think this should be OK.
Comment 9 Anton Leherbauer CLA 2010-09-28 07:08:17 EDT
Committed also to cdt_7_0.