Thread-safety issue in cmake support ?

[Nicolás Alvarez]

On 6/11/10, David Nolden <zwabel at googlemail.com> wrote:
> The big lock wouldn't eliminate multithreading at all.
>
> For example in the c++ support, it is needed only once at the beginning of a
> parse job to get the include paths, and maybe a few times during the code
> completion, which is quite tightly coupled to the UI anyway. Ok, it would
> also be required for using the new smart-ranges for highlighting, but that
> could be combined into one single locking per parsed open document, and thus
> wouldn't be critical.
>
> The important task is just to make sure the lock is used as seldomly as
> possible, and to make sure that all the heavy-lifting is done in a long
> continuous phase without the lock. That is easy for c++ support at least.

In my experience, the C++ parser *already* has too much lock
contention (from duchain locks). I rarely see KDevelop CPU usage go
above 100%.

I just tried wiping .kdevduchain and starting kdevelop again, and it
averaged 85% CPU usage during background parsing. It's configured to
use 2 threads and doesn't even manage to use a single CPU core
fully...

-- 
Nicolas