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

["Pruitt, John" <john.pruitt@xxxxxxxxxxxxx>]

Hi James,

Is the refresh at termination present to account for those cases where a
runtime invocation of a program changes the source which is used to
build this same program? And cases where gdb is used to change the
source? These don't seem like high-runner cases. Do a lot of users have
non-source files in their projects where these non-source files are
changed by the running program? Doing a refresh upon termination seems
safe and not a big penalty for small projects but when any refresh at
all is painful, obviously doing two is doubly so. 

I think you are suggesting that if the platform had different ways of
asking for and scheduling the refreshes then the refreshes would not be
so obnoxious to the user. But the refreshes could still present a
signficant load to the system and wouldn't it be better if CDT were to
reduce the number of refreshes that it requests? It doesn't seem like
this is just a platform problem.

John

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of James Blackburn
Sent: Thursday, February 12, 2009 2: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