RE: [cdt-dev] FYI, merged in a bunch of changes

["Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>]

James,
thanks for pointing out that the change to PDOMManager#addProject
is wrong, it would reintroduce
https://bugs.eclipse.org/bugs/show_bug.cgi?id=179644.
I have reverted the change.

Markus.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> Sent: Wednesday, May 12, 2010 10:42 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] FYI, merged in a bunch of changes
> Importance: Low
> 
> On 11 May 2010 23:55, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:
> > - Reworked the resulting concurrency fixes - indexing and scanner 
> > discovery now synchronize on the project root as a scheduling rule. 
> > Original HEAD behaviour was to synch on the project's 
> .settings folder 
> > for indexing, but that deadlocked with scanner discovery. 
> James, you 
> > will probably want to take a look at what I did there and make sure 
> > you are comfortable with it, as I know you have been trying 
> to relax 
> > the scheduling rules as much as possible. If you think it 
> needs some rework let me know.
> 
> I had a quick look, would it be possible for you to attach 
> thread-dumps to a bug so we can better see where this is going wrong?
> I haven't encountered any lock-ups in CDT 6/7.  (We use 
> ILocks to lock the project model, which have the benefit of 
> deadlock detection / resolution, and I know Toni and I have 
> both fixed a couple ordering issues here...)
> 
> The scheduling rule change in PDOMManager#addProject doesn't 
> look right to me.  Instead of asking the rule factory for a 
> base rule it's now fixed the at Project. Looking at Markus' 
> logic, the MutliRule created should always contain the 
> project, and as more pessimistic Team providers (e.g. CCRC) 
> might return different scheduling rules for refresh, it seems 
> wrong not to involve them.
> 
> In CfgDiscoveredPathManager, you've replace the synchronized 
> with a project scoped sched rule.  This is to work around a 
> deadlock in CDT 5, right? If we're just trying to enforce 
> mutual exclusion, then ILock would be better here (as done in 
> SelectionListenerWithASTManager).
> That way you still have deadlock detection/protection without 
> the need to know what rules the client code called requires, 
> and without checking into the workspace.
> 
> I'm a big one for collecting thread-dumps of lock-ups, it's a 
> good reminder / reference of how complicated the system is. 
> Please do attach them to bugs as and when you hit them!
> 
> Cheers,
> James
> 
> 
> > - Fixed remote indexing. Changes on HEAD that deprecated CodeReader 
> > broke the ability for remote translation units to provide 
> the path to 
> > load the file content from. Added API to ITranslationUnit 
> for this purpose.
> >
> > The tests all pass, but let me know if you run into any problems, 
> > particularly if you encounter any concurrency issues.
> >
> > FYI error parsing seems broken for remote projects. I 
> intend to start 
> > looking into that tomorrow.
> >
> > ===========================
> > Chris Recoskie
> > Team Lead, IBM CDT and RDT
> > IBM Toronto
> >
> > _______________________________________________
> > 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
>