RE: [cdt-dev] CDescriptor Behavior

["Pete MacLiesh" <pmac@xxxxxxxxxxxxx>]

Ha. We also ran into the cdtproject and events ... We have a fancy import that:

- creates an empty cdt project
- imports files including a .cdtproject
  - causing events that are queued up
- updates the cdescriptor in memory

Our problem was that the whole thing was in a WSmodifyop so the imported cdtproject was
not noticed and read from disk before the updates were made ... so the subsequent updates
were to the in memory empty copy ... and then later when events fired that was all
overwritten. We made updateFromDisk() public to force the reload under program control
before making our changes.

Getting the right granularity of wsmodify batching in eclipse is really hard.

Question: the cdtproject is really under program control (I don't see users wanting to
edit it by hand). Why is it ok that a disk modify event causes a read that just blows it
away? Seems like a callback to the project owner on what to do would be nice.


Ciao,

PMac
  

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ken.ryall@xxxxxxxxx
> Sent: Wednesday, June 14, 2006 12:28 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] CDescriptor Behavior
> 
> Hi,
> 
> I've been trying to fix a bug and have stumbled into some interesting
> aspects of using a CDescriptor that I thought I would share and see if
> anyone had thoughts or advice about. I'm working with CDT 3.0.2 and
> Eclipse 3.1.2 but I diffed the relevant files and didn't see 
> any reason
> why this wouldn't be a problem with the latest as well.
> 
> My code creates a project and then attempts to set it up to use three
> binary parsers:
> 
> ICDescriptorOperation op = new ICDescriptorOperation() {
> 
> 	public void execute(ICDescriptor descriptor, IProgressMonitor
> monitor) throws CoreException {
> 		descriptor.remove(CCorePlugin.BINARY_PARSER_UNIQ_ID);
> 		descriptor.create(CCorePlugin.BINARY_PARSER_UNIQ_ID,
> "parserOne");
> 		descriptor.create(CCorePlugin.BINARY_PARSER_UNIQ_ID,
> "parserTwo");
> 		descriptor.create(CCorePlugin.BINARY_PARSER_UNIQ_ID,
> "parserThree");
> 	}
> };
> CCorePlugin.getDefault().getCDescriptorManager().runDescriptor
> Operation(
> newProject.getProject(), op, null);
> 
> This is modeled after code in BinaryParserBlock which seems to work
> fine, but in my case the result is variable: sometimes the 
> projects ends
> up with one, two, or all three parsers set.
> 
> The problem seems to be that when you call CDescriptor.create it wants
> to save the new data to disk by creating and scheduling a
> CDescriptorUpdater job. Fair enough, except that if you call
> descriptor.create again while that job is still running the check in
> CDescriptor.updateOnDisk will detect this and will not try to create
> another job to write the new data. This leaves the descriptor with new
> data that's unsaved.
> 
> That would be OK since I assume it would be saved to disk at 
> some later
> point, but next we have org.eclipse.core.internal.events.AutoBuildJob
> lurking in wait for some changed projects to rebuild. It detects the
> changed resource and then fires off a IResourceChangeEvent.PRE_BUILD
> event. It does this even if the Build Automatically setting is off.
> 
> CDescriptorManager catches the event and decides it should update the
> project from disk. It calls updateFromDisk on the descriptor 
> which wipes
> out its new and unsaved data.
> 
> Of course all this happens on other threads while the three
> descriptor.create calls are being executed in their thread.
> 
> I'm working around this problem by waiting for the descriptor save job
> and the auto build job to complete before attempting to write 
> more data
> to the descriptor. Yet it seems like CDescriptor.create should either
> save the data for sure each time or at least mark the descriptor as
> dirty, or that CDescriptor.updateFromDisk should check for 
> unsaved data
> before loading something potentially stale.
> 
> There is an intriguing comment after the code in BinaryParserBlock,
> "Give a chance to the contributions to save" but I couldn't 
> associate it
> with anything.
> 
> Thanks - Ken
> 
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>