Current state of duchain/parser

[Jakob Petsovits]

On Sunday, 13. May 2007, Kris Wong wrote:
> > 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.

Kate(part) doesn't use any of DUChain, it's completely internal to KDevelop. 
It's only that DUChain itself relies on some of KTextEditor's features, and 
Hamish codes on both Katepart and KDevelop, so DUChain's usage of KTextEditor 
comes from a deep understanding of the latter. Which brings a slightly higher 
possibility that we get bugs that haven't yet been discovered elsewhere.

> 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.

Sounds like a cool approach to me.
Although it should be noted that KDevelop only has two threads now, but in 
principle DUChain was designed to be *very* concurrent. Like, one thread for 
every file or so - afaik, taking multi-threading to the max was one of 
Hamish's objectives on DUChain.

KMail doesn't show either of the files correctly (winmail.dat galore), but I 
find the overall idea quite ok, and if it fixes the assert while still 
working correctly in release mode, go for it!
(It's so great to see some work on DUChain.)

Have fun,
  Jakob