I have no problem with the fix for 5.0.1 as you've laid it out. I do
worry about potential corruption due to unsychronized access to the
descriptor data. But that's probably less likely than the deadlock.
It probably is unlikely, though I can corrupt the project model in CDT 5
by getting the indexer going and pressing apply rapidly in the Project
Properties dialog (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=239627).
Long term, though, i.e. 5.1, we need to get to the bottom of
this stuff.
In the short term the project model performance is a blocker for some of
our users with larger projects
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=238421). Next week I
should get a chance to start looking at a solution if no one else is
actively working on this. For large projects the XML tree and
associated objects takes a huge amount of memory to process -- the
duplication during modification is both tough on memory and processor
intensive. It would seem that a sensible solution would be to replace
the XML with a database (maybe SQLlite) trusting the data to something
built for random access storage?
Do the cdt-devs have any feelings either way on this? Should effort be
made to fix the code preserving the XML model already there, or would
there be support for using a database for storing the few MB of data?
Cheers,
James
Cheers,
Doug.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia
Sent: Thursday, July 17, 2008 2:07 PM
To: CDT General developers list.
Subject: [cdt-dev] deadlocks
I get across another dead-lock between jobs and locking
CProjectDescriptiorManager.
To fix it for good we may need to use eclipse locking which
can "undeadlock" things, but for now I want to apply simple
fix that applied to this particular problem
https://bugs.eclipse.org/bugs/show_bug.cgi?id=241288.
If nobody has any objections I would commit the patch.
Technically as Doug mentioned in pr, it can create other
problems, but I don't think it would in this particular case
because this method is called without the lock most of the
time (and this is maybe a reason that it is hard to reproduce
in practice).
_______________________________________________
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