Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] deadlocks

Personally I would not invest any time in databases. It is so much heavier and it is not the way platform goes. I would invest time in investigating why our xml files are so big and what other problems with the build model.

James Blackburn wrote:
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

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
(  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?



-----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

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 mailing list

cdt-dev mailing list

Back to the top