[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
> 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
>
>
