Re: [cdt-dev] DSF lockup with debugger-assisted run

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

BTW, I think it would be a good time to open a bug for this issue and 
take the discussion there.
-Pawel

On 09/30/2010 12:07 PM, Pawel Piech wrote:
> 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
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev