Re: [cdt-dev] GDB, Terminate, and project refresh(es)

[James Blackburn <jamesblackburn@xxxxxxxxx>]

I've file two bugs:
1) https://bugs.eclipse.org/bugs/show_bug.cgi?id=265498
2) https://bugs.eclipse.org/bugs/show_bug.cgi?id=265504
(1) is for this issue directly.

(2) is for the performance implications of all these refreshLocals CDT
currently does.  Interactive performance is really bad for users who
have non local filesystems.  I'm quite interested in attacking these
as they affect me day to day. If anyone has any input ideas, do
comment on the bugs :)!

2009/2/13 Mikhail Khodjaiants <Mikhail.Khodjaiants@xxxxxxx>:
> We can define an interface to extend IProcess so backends can notify the
> frontend when the project refresh is required.

We could do, but that just pushes the refresh decision somewhere else.
 Most users (and integrators!) wouldn't know / care whether they
should or shouldn't have refresh on by default. After all it's the
thing you're debugging which determines whether a refresh is needed,
not the debugger itself.

Cheers,

James

>
> Regards,
> Mikhail
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of James Blackburn
> Sent: Thursday, February 12, 2009 8:47 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] GDB, Terminate, and project refresh(es)
>
> Hi John,
>
>> Could there be an option to not do a refresh on terminate? (i.e. the
>> user "promises" that things won't change)
>
> The External Tool launcher has such a feature configurable via its
> "Refresh Tab".
>
>> Any idea why 2 refreshes are done?
>
> As far as consumers of the event are concerned there really are two
> things being terminated.  The RuntimeProcess is the thing being
> debugged, the ProcessProcess is the actual gdb debugger.
>
>> The context for the question is a user with a really large project (in
>> clearcase) where a refresh is a very long operation and needs to be
>> avoided if at all possible.  We have already added a "project migrate"
>> capability so that the project can be created by migrating from a
>> reference project into a developers project and the traditional
>> refresh is not performed. Instead, the refresh info from the reference
>
>> project is captured and used in the developers project. This saved
>> considerable time when the project was created but now there are other
>
>> refreshes being done and as you say, this is a huge source of
> frustration.
>
> Eek.  This isn't all that nice I see pauses during day to day work
> running on NFS.  Not nearly as bad as yours, I'm sure (I've witnessed
> ClearCase pain, it's orders of magnitude worse...).  A couple of things
> you could look into:
> 1) IBM have a page on ClearCase performance tuning:
> http://www.ibm.com/developerworks/rational/library/4268.html
> 2) You could also try CCRC?
> 3) IBM ClearCase MVFS refresh provider support With 3 you could neuter
> the places that do refreshLocal(...) in your CDT.  Not ideal by any
> means...
>
>> So far, when making a simple "hello" project and debugging it locally,
>
>> I see 3 refreshes. The first is when the project is being started and
>> seems to be part of a build. (is there a way to turn this off?) The
>> other 2 are associated with the Terminate.
>
> I think the first is probably at the end of the build.  The
> CommonBuilder does a refreshLocal of the project after running make.
>
>> Your suggestions of making the refreshes less obnoxious sound like a
>> good idea. Having options to control how many are being asked for,
>> especially refreshes at the project level, also seem desirable.
>
> Agree.  This is probably good fodder for e4
>
> Cheers,
> James
>
>>
>> Thanks.
>>
>> John
>>
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of James Blackburn
>> Sent: Thursday, February 12, 2009 11:23 AM
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] GDB, Terminate, and project refresh(es)
>>
>> For the same reason that proejct refresh occurs at the end of a build
>> -- running external tools may change the underlying project on disk.
>>
>> This seems to be a huge source of frustration for users.  On Linux, in
>
>> particular, Eclipse can quickly get out of sync with the filesystem --
>
>> I frequently see the "Resource is out of sync with filesystem" error
>> in the editor on open (and yes, I do have automatically refresh
>> workspace on). The fix is a manual refresh of that file -- why the
>> editor can't do this for me (or ignore the sync bits) is beyond me.
>> [I've filed & commented on bugs to this effect and the Platform guys
>> don't seem to get that there's a usability issue.]
>>
>> What would be neat is some API to say:
>> Schedule a refresh of this sub-tree, it may have changed, but do the
>> best effort as a separate Job.  By best effort I mean don't block
>> anything else that may want to lock resources or run with resource
>> scheduling rules. And if a Job tries to run with a scheduling rule,
>> then let the Job preempt the refresh.
>>
>> That platform already does something like this for auto-build. If an
>> auto-build is running when you do Workspace.run() with some scheduling
>
>> rule it will interrupt it. It would surely be possible to extend /
>> improve the RefreshManager to be user (ISV) driven.  (Taking a quick
>> look at the code, RefreshManager.refresh(IResource) already exists but
>
>> this Manager is currently internal...)
>>
>> Of course there are valid reasons for running the refresh in the
>> current thread. For example at the end of build it's used for creating
>
>> the resource delta for the next build. [Though this might be breaking
>> for other reasons -- allowing builds to run with less than workspace
>> root scheduling rule...]
>>
>> It seems that a lot of places where we do IResource.refreshLocal(...)
>> in the current thread, with the current locks, would be better
>> deferred and scheduled to the background best effort?
>>
>> Does anyone have any thoughts on this?
>>
>> James
>>
>> 2009/2/12 Pruitt, John <john.pruitt@xxxxxxxxxxxxx>:
>>> In
>>> org.eclipse.cdt.launch/src/org/eclipse/cdt/launch/internal/ui/LaunchU
>>> I Plugin.java there is a function called handleDebugEvents. If the
>>> event
>>
>>> is a TERMINATE for a Process-like object, it looks like it does a
>>> refresh of the project associated with the process being terminated.
>>>
>>> When a simple project like hello is started with run->debug using GDB
>
>>> and then a "Terminate and Relaunch" action is chosen on this process,
>
>>> there appear to be two TERMINATE events created for Process-like
>>> objects. These two events are created at:
>>>
>>> RuntimeProcess.fireTerminateEvent
>>> GDBProcess.fireTerminateEvent
>>>
>>> I was wondering about two things.
>>>
>>> 1. Why is a project refreshed when a debug Terminate action is
> chosen?
>>> 2. Why is the project refreshed twice?
>>>
>>> Thanks.
>>>
>>> John Pruitt
>>> Wind River Systems
>>> 630-971-6430
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> --
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>