Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] PDom locking, lifecycle of PDom objects 
The point is that definitions for references are not necessarily
part of the same project:

Project A:
  File: library.h:  void lib_func();
  File: library.c:  void lib_func() {}
  File: testLibrary.c: int main(int argc, char** argv) { lib_func();} 

Project B:
  File: main.c:  int main(int argc, char** argv) { lib_func();}

In case I want to show the call hierarchy for 'lib_func', I need to
search the PDom of project A and B.

I currently make this happen by using PDOMLinkage.adaptBinding() to
convert the PDOMBinding from the one PDOM to the other. 

Markus.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> Sent: Dienstag, 05. September 2006 15:19
> To: CDT General developers list.
> Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> 
> Hmm, I'm a little confused. PDOM's don't know about 
> eachother. So I'm not
> sure what you meant by (c). Once you have the IASTName, you ask the
> IPDOMResolver to resolve the IBinding, then from there you 
> can navigate to
> references or definitions or declarations. You would have to 
> do that for
> each PDOM. It certainly wasn't my intention that you can use 
> PDOM objects
> from one PDOM to navigate to objects in another PDOM. Given 
> that, you would
> only need to lock one PDOM at a time.
> 
> Doug Schaefer
> QNX Software Systems
> Eclipse CDT Project Lead
> http://cdtdoug.blogspot.com
>  
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Schorn, Markus
> Sent: Tuesday, September 05, 2006 8:15 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> 
> Doug,
> 
> I avoided using PDom objects in the model of the Call Hierarchy,
> so that should be ok. 
> Yet I work with the PDOM to find the references. For that I have
> to access multiple PDOMs and I can see a problem with that, because
> I cannot obtain the locks on multiple PDOMs without taking the risk
> of a deadlock. 
> 
> Here is what I do
> (a) convert input from ICElement to IASTName.
> (b) find references for the IASTName in PDom.
> (c) find definitions for references in multiple PDoms
> (d) convert definitions to ICElements.
> 
> (c) is the problematic step as I have to use the reference found in
>     a PDom to search for definitions in all other PDoms.
> 
> I'll be happy to discuss this at the summit.
> 
> Markus.
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> > Sent: Dienstag, 05. September 2006 13:42
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> > 
> > Sorry, Markus, I was trying very hard not to work on the 
> > holiday yesterday
> > ;). 
> > The PDOM is probably immature in this area, which is one 
> > reason why the
> > Index View is hidden and not recommended for heavy use. The 
> > PDOM does have a
> > read/write lock on it. While you are looking at objects you 
> > should have the
> > read lock turned on. You shouldn't keep them around long 
> > term. That is the
> > role of the ICElement objects. That comes back to the need to 
> > be able to
> > create ICElement objects from the PDOM and to update them 
> > based on PDOM
> > updates. That would probably make your life easier.
> > 
> > This is something we need to talk about at the Summit. I'll have a
> > presentation there that will hopefully clarify what the 
> > architecture is
> > supposed to be.
> > 
> > Doug Schaefer
> > QNX Software Systems
> > Eclipse CDT Project Lead
> > http://cdtdoug.blogspot.com
> >  
> > 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> > Behalf Of Schorn, Markus
> > Sent: Tuesday, September 05, 2006 4:19 AM
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> > 
> > Hi Doug,
> > please help me out on this, I really need to understand how 
> > to correctly
> > use locks on the PDom. I try to restate my question:
> > 
> > The implementation of the Call Hierarchy has the need to work 
> > with multiple PDoms, because such hierarchies may span over multiple
> > projects. I must not simultaneously hold locks of multiple PDoms
> > as this would lead to dead-locks. So I have to avoid locks where
> > possible and I have to understand under which circumstances this
> > is reasonable to do.
> > 
> > If there is no safe way to work with multiple PDoms we should
> > make changes to our architecture. That's why I'd like to understand
> > this as soon as possible.
> > 
> > Markus.
> > 
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx 
> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
> > > Sent: Montag, 04. September 2006 15:26
> > > To: CDT General developers list.
> > > Subject: [cdt-dev] PDom locking, lifecycle of PDom objects
> > > 
> > > Hi,
> > > I am trying to understand how to safely use the PDom. I have 
> > > a bunch of
> > > questions. I can only ask the first one, as the next one will 
> > > depend on
> > > the first answer. 
> > > 
> > > Objects obtained by the PDOM (e.g. PDOMName) will actually 
> > access the
> > > database when I invoke methods (e.g. 
> > PDOMName.toCharArray()) on them.
> > > What happens if the database was modified after the PDOM 
> object was
> > > handed to me?
> > > 
> > > Markus.
> > > _______________________________________________
> > > 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
> > 
> _______________________________________________
> 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
>

Back to the top