[cdt-dev] CDescriptor Behavior

[<ken.ryall@xxxxxxxxx>]

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().runDescriptorOperation(
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