I
opened Bug 325394
- some times the user cannot step for 5 seconds during fast stepping
Thanks
Dobrin
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Wednesday, September 15, 2010 3:13 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] DsfSourceDisplayAdapter question
I think your analysis makes perfect sense and so does the
suggested fix. I only wonder why the call to
displaySource(eventtriggered==false) overrides the one with
eventTriggered==true. Toni added this feature he may be able to comment
on it better.
Cheers,
Pawel
On 09/15/2010 11:05 AM, Alexiev, Dobrin wrote:
Thanks Pawel, I should have
noticed executeFromJob!
Here is more detailed analysis
of the problem I’m seeing:
DsfSourceDisplayAdapter.startDisplayJob()
is called with eventTriggered = true.
A DisplayJob() with
eventTriggered = true is created and scheduled.
Right after that
DsfSourceDisplayAdapter.startDisplayJob() is called with eventTriggered = false.
The previous DisplayJob is
canceled :fRunningDisplayJob.cancel(); but its run() never had chance to
execute, therefore never call doneStepping(fResult.getDmc());
That will prevent StepController
to allow further stepping.
I did simple experimenting
by adding these two lines of code just before:
fRunningDisplayJob.cancel();
if(
fRunningDisplayJob.fEventTriggered)
doneStepping(fRunningDisplayJob.fResult.getDmc());
After adding these two lines the
issue is gone!
I don’t understand
DsfSourceDisplayAdapter 100% yet, but I wanted to check with you if this is
correct use case for the class.
If a display job is to be
canceled should we make sure that doneStepping is called on its behalf.
Or may be if the display job is
preempted by another display job we somehow transfer the doneStepping
responsibility.
Or may be somehow the use case
I’m describing should be prevented in another place.
Thanks
Dobrin
Hi Dobrin,
You should trust the comment that this method should be only called in the
session thread. Looking at the method you mentioned though:
protected IStatus run(final IProgressMonitor monitor) {
if (monitor.isCanceled()) {
return Status.CANCEL_STATUS;
}
final SourceLookupResult result = performLookup();
executeFromJob(new DsfRunnable() { public void run() {
if (!monitor.isCanceled()) {
fPrevResult = result;
fPrevFrameData = fFrameData;
fRunningLookupJob = null;
startDisplayJob(fPrevResult, fFrameData, fPage, fEventTriggered);
}
}});
return Status.OK_STATUS;
}
It seems that startDisplayJob() should always be called on the services session
thread as guranteed by executeFromJob().
-Pawel
On 09/15/2010 08:46 AM, Alexiev, Dobrin wrote:
Hello,
I noticed that DsfSourceDisplayAdapter. startDisplayJob is
being called from a worker thread DsfSourceDisplayAdapter.LookupJob.run().
At the same time there is a comment for
DsfSourceDisplayAdapter. startDisplayJob “ To be called only on dispatch
thread.”
I am debugging a problem that the DsfSourceDisplayAdapter.
doneStepping is not called and that prevents the user from further stepping.
I’ll debug further the issue but I was wandering:
should I trust the comment or;
the method is intended to be called
from multiple threads?
Thanks
Dobrin
_______________________________________________
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