Skip to main content

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

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



> 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 
> >
> > 
> > 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
> >
> > 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top