[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] DSF lockup with debugger-assisted run
|
On 09/30/2010 11:30 AM, Vladimir Prus wrote:
On Thursday, September 30, 2010 21:01:02 Pawel Piech wrote:
Hi Volodoya,
I think the correct method to handle this is to invent a new state:
"intederminate" in the GDB debugger integration (it could also be pushed
into the DSF IRunControl service). If target is in this state, then the
UI would know not to fetch the stack data.
Hi Pawel,
could you clarify where exactly in code the decision not to fetch stack data
should be made? Say, is StackFramesVMNode.buildDeltaForSuspendedEvent
a good place to put this logic in?
StackFramesVMNode.updateHasElementsInSessionThread() would be the
place. The buildDelta...() methods are only for event processing, and
they themselves fetch data through the update...() methods. In general,
you can suppress generating of a refresh event to the view, but you
can't completely control when the view retrieves data from the model to
paint itself. For that reason, suppressing events to avoid showing
something is not a good strategy. First you need to make sure that your
model returns accurate data, then worry about suppressing events to
avoid needless refreshes (and improve performance).
This is how we solved a
similar problem in the Wind River debugger.
I assume that debugger is DSF-based? Maybe, the best approach is for you to
contribute a patch? ;-)
If everyone took this approach we probably wouldn't have CDT, or much
open source software for that matter :-D
I could add this API extension, but I honestly don't when I will get the
time to do it. If you need something now, you're best of doing it
yourself. I also have no business reason to implement GDB features.
Otherwise, you could just
handle the problem in the stack service and decide not to return any
stack frames.
That's possible, but then it sounds backward to have DSF core decide we need
threads and propagate request all the way to MIStack, for it to return
nothing.
I agree. It just saves you from adding a new method to the API and from
having your own extension to the common UI code.
I'm rather confused about your use case though. Do you want to suppress
showing the stack frame, or from showing the thread (or some other
execution context)? If you don't want to show the execution context,
you'll need to modify ThreadsVMNode instead.
Cheers,
Pawel
- Volodya
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
