DU-chain classes questions ...

[Milian Wolff]

On Thursday 15 April 2010 03:28:06 Sandro Andrade wrote:
> Hi all ...
> 
> Could anyone please (maybe Nolden, Apol, or Milian) help me to clarify some
> points about
> the use of DU-chain classes ? I'm running some problems related to
> thread-safety of DU-chain
> objects, symbol table, and updating of top-contexts. So, here they are:
> 
> I can find out four classes for declarations: Declaration,
> IndexedDeclaration, DUChainPointer<Declaration> (DeclarationPointer),
> and DeclarationId and three classes for top contexts: TopDUContext,
> IndexedTopDUContext, and ReferencedTopDUContext.
> 
> 1) Apparently while Declaration holds the entire data, IndexedDeclaration
> keeps just an index to actual
> declaration data, right ?

Indeed. This means that nothing (not much) needs to be loaded from disk to use 
the Indexed* versions. To get the actual values though, you'll need to load 
from disk, which can be slow (depending whether the declaration is already in 
memory or not).

See also API doc to IndexedTopDUContext:
///Allows simple indirect access to top-contexts with on-demand loading

This is also the reason why one should always try to use Indexed* for equality 
comparison.

> 2) Looking at contextbrowser plugin source code, it seems that I must
> always use IndexedDeclaration
> instead of Declaration for those data which are going to be used across
> DU-Chain locks and probably defined as member attributes. Is this correct ?
> If yes, I still need to check if IndexedDeclaration::data() return a
> non-zero declaration, right ?

I think that it makes sense in this area of usage. It's not slow if the 
declaration is still in memory. If it's not, it's tried to load it from disk. 
But since anything could have happened in the meantime, e.g. the declaration 
could have been removed, you still have to check whether the data is still 
valid.

> 3) Would I get the same result by using DeclarationId ? I'm still confused
> about when to use a specific declaration class (IndexedDeclaration,
> DeclarationPointer, DeclarationId).

Ok, here you get me ;-) I never used the DeclarationId up until now afaik. But 
I saw that it's used somewhere. Anyways, reading it's API docs you see that it 
does more than the IndexedDeclaration. And probably this:

 * \note This only works when the Declaration is in the symbol table.

Is something you don't want, or? I personally don't know whether this is a 
requirement for the ControlflowGraph plugin. Anyways, if it works with 
IndexedDeclaration, use that one. Should have less overhead than the 
DeclarationId.

Oh and here a note to the ...Pointer classes: Take a look at DUChainPointer, 
it uses the KShared for it's data. The API-Docs are pretty clear what it does 
and where it should be used.

Again, you have to wager on what to use in your plugin. I'd say go for the 
Indexed* version, since there you can reload the object on-demand. If the 
DUChainPointer is zero, you can't do anything.

Note to others: Acutally I think we should/could use the Indexed* in more 
classes ;-)

> 4) I've seen someplace that a declaration can only be used from other
> contexts if it is in the symbol table. That's because
> of IndexedDeclaration keeps just the index to declaration in symbol table ?
> So, should I always check this if I want to
> use a declaration acquired in other context ?

Hm. I thought Indexed can work with any declaration... But again here you got 
me. I also see that there is a IndexedLocalDeclaration that's specific to a 
TopDUContext and doesn't has the "global" in it's API docs... Anyways, 
something David has to comment probably.

> 5) Apparently ContextBrowser plugin doesn't collect the uses of a
> declaration in background. However, UI doesn't
> block, I guess because of the assynchronous call to updateContextForUrl. Is
> this right ?

Yes, again: Take a look at the API docs.

> 6) If I select a new symbol while collecting uses, apparently the collect
> is paused and resumed from the last point if first symbol is selected
> again. The pause point can be restored from m_waitForUpdate and
> m_updateReady QSets in UsesCollector, but the question is: are the
> remaining updateContextForUrl calls cancelled when a new symbol is
> selected ? Or do they run to completion ?

They probably run until completion. Just a guess though. But I mean you don't 
have any API to abortJobForUrl or anything like that. And it shouldn't matter 
that much, since most of the time you'll switch symbols in a single context. 
If you jump to another context, it will get reparsed anyways for the editor, 
and there'll be only one job for that in the BackgroundParser.

Did you experience problems where too many (obsolete) jobs are still running? 
I never encountered that problem (at least not knowingly).

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100415/2ad3ece8/attachment.sig>