hi Doug, Markus,
would it be worth having one more
indexing conference call before the fall summit?
(it would be good to have a discussion about this,
#74433 and #149565)
thanks,
Andrew
cdt-dev-bounces@xxxxxxxxxxx wrote on 05/09/2006
14:19:07:
> 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
Don't miss out on your chance to...Do more with Symbian.
Make
sure you visit the Symbian Smartphone Show, 17-18 October
2006, Excel,
London
www.symbiansmartphoneshow.com
*******************************************************************
***
Symbian Software Ltd is a company registered in England and
Wales with
registered number 4190020 and registered office at 2-6
Boundary Row,
Southwark, London, SE1 8HP, UK. This message is
intended only for use by
the named addressee and may contain
privileged and/or confidential
information. If you are not the
named addressee you should not disseminate,
copy or take any action
in reliance on it. If you have received this
message in error
please notify postmaster@xxxxxxxxxxx and delete the
message and any
attachments accompanying it immediately. Neither Symbian
nor any of
its Affiliates accepts liability for any corruption,
interception,
amendment, tampering or viruses occurring to this message
in
transit or for any message sent by its employees which is not
in
compliance with Symbian corporate policy.
*************************
*********************************************