Current state of duchain/parser

[Kris Wong]

> task #1: figure out how to fix the assert when you load a project
> with the c++ parser enabled.

I have fixed the assert, although the changes were more extensive than I would have liked.  Also, I am not sure how this affects the Kate team and what parts of DUChain they are using.

There were several problems in the sanity check macros (ENSURE_CHAIN_READ_LOCKED and ENSURE_CHAIN_WRITE_LOCKED).  Rather than nitpick at these, it's easier just to say QReadWriteLock does not provide the functionality we need for these macros.  It's not possible to check if a thread has a read lock, and it's not convenient to check if a thread has a write lock.  That being said, there are two solutions:

1. Remove the sanity check macros - bad idea for obvious reasons.
2. Use a custom locking scheme.

I just happened to have attached the source for #2.  You will notice that depending on whether it is a debug build or non-debug build, DUChainLock switches back to being a QReadWriteLock.  I do not think we need this; in fact QReadWriteLock has a bit of additional overhead with its wait conditions that prevent readers from getting a lock when writers are waiting, etc...  KDevelop only have 2 threads, this is not necessary.  I threw it in there just in case.  Another benefit of this lock class is that you can see which threads have the DUChain locked at any time.

Any experts in this area please chime in.

Kris Wong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 34935 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070513/f610512d/attachment.bin>