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

[James Blackburn <jamesblackburn@xxxxxxxxx>]

2009/2/12 Pruitt, John <john.pruitt@xxxxxxxxxxxxx>:
> Any idea why 2 refreshes are done?

Oh yes, and actually doing the refresh twice is a bug.

The following bug might also be interesting -- a guy has 75,000
resources in a ClearCase filesystem and stat'ing all the files takes 8
mins...
https://bugs.eclipse.org/bugs/show_bug.cgi?id=74392

Perhaps what we should do, for the moment at least, is to turn on
"Refresh Automatically" in the workspace preferences (i.e. set as
default on the CDT Project).  Then we can remove a bunch of the
refreshLocal() -- in particular the refreshLocal at debugger session
tear-down and end of 'standard' make.

The Polling provider does use extra cycles in however it doesn't need
to hold any resource locks while doing so.  Refreshing the delta'd
resources and firing the resource change event do hold resource locks.
 This, I believe, is a better solution than the full project refreshes
especially for guys on really slow filesystems like ClearCase / NFS.

Anyone else have any strong feelings on this?

James

>
> 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.
>
> 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.
>
> 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.
>
> 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/LaunchUI
>> 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
>