Thread-safety issue in cmake support ?
zwabel at googlemail.com
Fri Jun 11 15:00:59 UTC 2010
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.
Am 09.06.2010 20:00 schrieb "Esben Mose Hansen" <kde at mosehansen.dk>:
On Wednesday 09 June 2010 18:12:47 Christoph Cullmann wrote:
> Then you are stuck more or less with ...
Both can be done in parallel, actually. If a BKL were implemented, it would
then be possible to walk around and eliminate each usage of it (except in
Kind regards, Esben
KDevelop-devel mailing list
KDevelop-devel at kdevelop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel